c'est un problème classique dont je ne trouve pas la solution ni dans la
KB ni dans les archives. J'ai peut-être mal cherché, un lien vers une
FAQ ou un HOWTO adapté est donc le bienvenu.
J'ai déjà rencontré ce problème sous NT4 il y a quelques années, mais je
ne me souviens plus de ce que l'on avait fait pour le résoudre (ou bien
le contourner).
J'ai un service, apache en l'occurence, qui doit accéder à des fichiers,
les fichiers à servir, sur un lecteur réseau. L'unité est mappée sur z:
et est physiquement située sur un serveur sous linux qui fait tourner samba.
L'unité n'est pas mappée au démarrage de la session, donc le service ne
peut démarrer automatiquement, dommage, mais ce n'est pas grave (je
préfère ne pas stocker le mot de passe).
Je mappe l'unité à la main, et j'accède sans problème aux fichiers de
l'unité ainsi mappée.
Je démarre le service qui, lui, n'y parvient pas, et s'arrête.
Le service fonctionne pourtant avec le même utilisateur que celui qui a
mappé l'unité.
L'utilisateur en question est administrateur, et a le droit d'ouvrir une
session en tant que service (le service démarre, mais s'arrête sur
l'erreur d'accès à l'unité z:).
Démarrer apache à la main depuis une console contourne le problème.
Comment faire pour qu'il puisse être démarrer en tant que service dans
ces conditions ?
Merci de votre aide,
--
Stanislas Renan
http://www.volcane.fr/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pierre Goiffon
"Stanislas Renan" a écrit dans le message de news:40e410c0$0$29384$
J'ai un service, apache en l'occurence, qui doit accéder à des fichiers, les fichiers à servir, sur un lecteur réseau. L'unité est mappée sur z: et est physiquement située sur un serveur sous linux qui fait tourner samba.
L'unité n'est pas mappée au démarrage de la session, donc le service ne peut démarrer automatiquement, dommage, mais ce n'est pas grave (je préfère ne pas stocker le mot de passe). Je mappe l'unité à la main, et j'accède sans problème aux fichiers de l'unité ainsi mappée. Je démarre le service qui, lui, n'y parvient pas, et s'arrête. Le service fonctionne pourtant avec le même utilisateur que celui qui a mappé l'unité.
Votre lecteur est mappé dans votre session, pas dans le contexte du service ! Utilisez plutôt le chemin UNC (nommachinenompartage...), et vérifiez que l'utilisateur avec lequel tourne le service a bien le droit (cf stratégie) d'accéder aux partages réseaux, et a l'authorisation d'accéder au partage sur la machine.
"Stanislas Renan" <stanislas.enlevezca.renan@volcane.fr> a écrit dans
le message de news:40e410c0$0$29384$626a14ce@news.free.fr
J'ai un service, apache en l'occurence, qui doit accéder à des
fichiers, les fichiers à servir, sur un lecteur réseau. L'unité est
mappée sur z:
et est physiquement située sur un serveur sous linux qui fait tourner
samba.
L'unité n'est pas mappée au démarrage de la session, donc le service
ne peut démarrer automatiquement, dommage, mais ce n'est pas grave (je
préfère ne pas stocker le mot de passe).
Je mappe l'unité à la main, et j'accède sans problème aux fichiers de
l'unité ainsi mappée.
Je démarre le service qui, lui, n'y parvient pas, et s'arrête.
Le service fonctionne pourtant avec le même utilisateur que celui qui
a mappé l'unité.
Votre lecteur est mappé dans votre session, pas dans le contexte du service
! Utilisez plutôt le chemin UNC (\nommachinenompartage...), et vérifiez
que l'utilisateur avec lequel tourne le service a bien le droit (cf
stratégie) d'accéder aux partages réseaux, et a l'authorisation d'accéder au
partage sur la machine.
"Stanislas Renan" a écrit dans le message de news:40e410c0$0$29384$
J'ai un service, apache en l'occurence, qui doit accéder à des fichiers, les fichiers à servir, sur un lecteur réseau. L'unité est mappée sur z: et est physiquement située sur un serveur sous linux qui fait tourner samba.
L'unité n'est pas mappée au démarrage de la session, donc le service ne peut démarrer automatiquement, dommage, mais ce n'est pas grave (je préfère ne pas stocker le mot de passe). Je mappe l'unité à la main, et j'accède sans problème aux fichiers de l'unité ainsi mappée. Je démarre le service qui, lui, n'y parvient pas, et s'arrête. Le service fonctionne pourtant avec le même utilisateur que celui qui a mappé l'unité.
Votre lecteur est mappé dans votre session, pas dans le contexte du service ! Utilisez plutôt le chemin UNC (nommachinenompartage...), et vérifiez que l'utilisateur avec lequel tourne le service a bien le droit (cf stratégie) d'accéder aux partages réseaux, et a l'authorisation d'accéder au partage sur la machine.
Johann Dantant
"Stanislas Renan" a écrit dans le message de news:40e410c0$0$29384$
J'ai un service, apache en l'occurence, qui doit accéder à des fichiers, les fichiers à servir, sur un lecteur réseau. L'unité est mappée sur z: et est physiquement située sur un serveur sous linux qui fait tourner
samba.
Donc il faut qu'Apache tourne sous une identité utilisateur particulière, et non comme compte système...
(...)
Je mappe l'unité à la main, et j'accède sans problème aux fichiers de l'unité ainsi mappée. Je démarre le service qui, lui, n'y parvient pas, et s'arrête. Le service fonctionne pourtant avec le même utilisateur que celui qui a mappé l'unité.
Donc j'imagine que c'est bon...
L'utilisateur en question est administrateur, et a le droit d'ouvrir une session en tant que service (le service démarre, mais s'arrête sur l'erreur d'accès à l'unité z:).
Ben oui, le mapping Z: est a priori propre à ta session utilisateur, ce n'est pas parce que le service à la même identité qu'il a la même session (même si avec NT4 c'est un peu bizaroide à ce niveau puisque le noyau n'isole pas correctement les sessions services de la session interactive). Donc je vois deux possibilités : - la possibilité simple fiable et éprouvée, c'est d'accéder aux fichiers par leur nom UNC (machinepartagerépertoirefichier) sans passer par le montage de disque réseau - la possibilité moins simple et sujette à effets de bord, c'est de s'appuyer sur un script de login (ou une stratégie sur l'utilisateur ?) pour que le service retrouve son montage à coup sûr, mais autant que je me souvienne, sur NT4 au moins le disque monté par le service apparaît dans les disques accessibles par l'utilisateur, même si l'utilisateur n'a pas la même identité, donc, mauvaise idée à mon sens.
J.D. -- Le message sur le NG c'étais pour tenir informé de l'avancement du site!Si g voulu en tenir informé le monde C parce que je pensais que vous étiez interressés par le site et que vous aviez hâte qu'il sorte! -+- Pip99 in http://www.petitjoueur.net/ : nzn.fr.jeux.pip99 -+-
"Stanislas Renan" <stanislas.enlevezca.renan@volcane.fr> a écrit dans le
message de news:40e410c0$0$29384$626a14ce@news.free.fr...
J'ai un service, apache en l'occurence, qui doit accéder à des fichiers,
les fichiers à servir, sur un lecteur réseau. L'unité est mappée sur z:
et est physiquement située sur un serveur sous linux qui fait tourner
samba.
Donc il faut qu'Apache tourne sous une identité utilisateur particulière, et
non comme compte système...
(...)
Je mappe l'unité à la main, et j'accède sans problème aux fichiers de
l'unité ainsi mappée.
Je démarre le service qui, lui, n'y parvient pas, et s'arrête.
Le service fonctionne pourtant avec le même utilisateur que celui qui a
mappé l'unité.
Donc j'imagine que c'est bon...
L'utilisateur en question est administrateur, et a le droit d'ouvrir une
session en tant que service (le service démarre, mais s'arrête sur
l'erreur d'accès à l'unité z:).
Ben oui, le mapping Z: est a priori propre à ta session utilisateur, ce
n'est pas parce que le service à la même identité qu'il a la même session
(même si avec NT4 c'est un peu bizaroide à ce niveau puisque le noyau
n'isole pas correctement les sessions services de la session interactive).
Donc je vois deux possibilités :
- la possibilité simple fiable et éprouvée, c'est d'accéder aux fichiers par
leur nom UNC (\machinepartagerépertoirefichier) sans passer par le
montage de disque réseau
- la possibilité moins simple et sujette à effets de bord, c'est de
s'appuyer sur un script de login (ou une stratégie sur l'utilisateur ?) pour
que le service retrouve son montage à coup sûr, mais autant que je me
souvienne, sur NT4 au moins le disque monté par le service apparaît dans les
disques accessibles par l'utilisateur, même si l'utilisateur n'a pas la
même identité, donc, mauvaise idée à mon sens.
J.D.
--
Le message sur le NG c'étais pour tenir informé de l'avancement du
site!Si g voulu en tenir informé le monde C parce que je pensais que
vous étiez interressés par le site et que vous aviez hâte qu'il sorte!
-+- Pip99 in http://www.petitjoueur.net/ : nzn.fr.jeux.pip99 -+-
"Stanislas Renan" a écrit dans le message de news:40e410c0$0$29384$
J'ai un service, apache en l'occurence, qui doit accéder à des fichiers, les fichiers à servir, sur un lecteur réseau. L'unité est mappée sur z: et est physiquement située sur un serveur sous linux qui fait tourner
samba.
Donc il faut qu'Apache tourne sous une identité utilisateur particulière, et non comme compte système...
(...)
Je mappe l'unité à la main, et j'accède sans problème aux fichiers de l'unité ainsi mappée. Je démarre le service qui, lui, n'y parvient pas, et s'arrête. Le service fonctionne pourtant avec le même utilisateur que celui qui a mappé l'unité.
Donc j'imagine que c'est bon...
L'utilisateur en question est administrateur, et a le droit d'ouvrir une session en tant que service (le service démarre, mais s'arrête sur l'erreur d'accès à l'unité z:).
Ben oui, le mapping Z: est a priori propre à ta session utilisateur, ce n'est pas parce que le service à la même identité qu'il a la même session (même si avec NT4 c'est un peu bizaroide à ce niveau puisque le noyau n'isole pas correctement les sessions services de la session interactive). Donc je vois deux possibilités : - la possibilité simple fiable et éprouvée, c'est d'accéder aux fichiers par leur nom UNC (machinepartagerépertoirefichier) sans passer par le montage de disque réseau - la possibilité moins simple et sujette à effets de bord, c'est de s'appuyer sur un script de login (ou une stratégie sur l'utilisateur ?) pour que le service retrouve son montage à coup sûr, mais autant que je me souvienne, sur NT4 au moins le disque monté par le service apparaît dans les disques accessibles par l'utilisateur, même si l'utilisateur n'a pas la même identité, donc, mauvaise idée à mon sens.
J.D. -- Le message sur le NG c'étais pour tenir informé de l'avancement du site!Si g voulu en tenir informé le monde C parce que je pensais que vous étiez interressés par le site et que vous aviez hâte qu'il sorte! -+- Pip99 in http://www.petitjoueur.net/ : nzn.fr.jeux.pip99 -+-
Stanislas Renan
Pierre Goiffon wrote:
Votre lecteur est mappé dans votre session, pas dans le contexte du service !
ah, d'accord.
> Utilisez plutôt le chemin UNC (nommachinenompartage...), Ça fonctionne à merveille.
Merci, et merci à Johann également. -- Stanislas Renan http://www.volcane.fr/
Pierre Goiffon wrote:
Votre lecteur est mappé dans votre session, pas dans le contexte du service
!
ah, d'accord.
> Utilisez plutôt le chemin UNC (\nommachinenompartage...),
Ça fonctionne à merveille.
Merci, et merci à Johann également.
--
Stanislas Renan
http://www.volcane.fr/
Votre lecteur est mappé dans votre session, pas dans le contexte du service !
ah, d'accord.
> Utilisez plutôt le chemin UNC (nommachinenompartage...), Ça fonctionne à merveille.
Merci, et merci à Johann également. -- Stanislas Renan http://www.volcane.fr/
Pierre Goiffon
"Johann Dantant" a écrit dans le message de news:cc15hv$of1$
Ben oui, le mapping Z: est a priori propre à ta session utilisateur, ce n'est pas parce que le service à la même identité qu'il a la même session (même si avec NT4 c'est un peu bizaroide à ce niveau puisque le noyau n'isole pas correctement les sessions services de la session interactive).
Est-ce que vous auriez plus de détails ?
"Johann Dantant" <news-dot-jd@pro-dash-active-dot-fr.INVALID> a écrit
dans le message de news:cc15hv$of1$1@news-reader2.wanadoo.fr
Ben oui, le mapping Z: est a priori propre à ta session utilisateur,
ce n'est pas parce que le service à la même identité qu'il a la même
session (même si avec NT4 c'est un peu bizaroide à ce niveau puisque
le noyau n'isole pas correctement les sessions services de la session
interactive).
"Johann Dantant" a écrit dans le message de news:cc15hv$of1$
Ben oui, le mapping Z: est a priori propre à ta session utilisateur, ce n'est pas parce que le service à la même identité qu'il a la même session (même si avec NT4 c'est un peu bizaroide à ce niveau puisque le noyau n'isole pas correctement les sessions services de la session interactive).
Est-ce que vous auriez plus de détails ?
Stanislas Renan
Stanislas Renan wrote:
> Utilisez plutôt le chemin UNC (nommachinenompartage...), Ça fonctionne à merveille.
Pour info, apache démarre et trouve ses fichiers distants. PHP est en module, et trouve ses fichiers également.
En revanche, une commande système exécutée par la fonction PHP system() ne trouve pas ses fichiers. En exécutant un simple "cd" via system(), je remarque que, lorsque apache est lancé dans l'environnement utilisateur interactif, depuis un shell et dans un répertoire quelconque, system s'exécute toujours dans le répertoire attendu (celui du script, soit z:chemin).
Lorsqu'apache est lancé en tant que service, le répertoire est toujours %SYSTEMROOT% (enfin, je constate que c'est c:windows).
C'est peut-être un problème lié à apache, PHP ou autre, mais peut-être est-ce plus simplement un comportement du système qui est normal et que je ne comprends pas. Y a-t-il une explication et une éventuelle solution (system('cmd.exe /C cd hostpath && commande') ne fonctionne pas) ?
Je préfère me renseigner avant de faire un rapport d'incident invalide dans apache.
Heureusement, la configuration finale sera intégralement locale...
merci -- Stanislas Renan http://www.volcane.fr/
Stanislas Renan wrote:
> Utilisez plutôt le chemin UNC (\nommachinenompartage...),
Ça fonctionne à merveille.
Pour info, apache démarre et trouve ses fichiers distants.
PHP est en module, et trouve ses fichiers également.
En revanche, une commande système exécutée par la fonction PHP system()
ne trouve pas ses fichiers.
En exécutant un simple "cd" via system(), je remarque que, lorsque
apache est lancé dans l'environnement utilisateur interactif, depuis un
shell et dans un répertoire quelconque, system s'exécute toujours dans
le répertoire attendu (celui du script, soit z:chemin).
Lorsqu'apache est lancé en tant que service, le répertoire est toujours
%SYSTEMROOT% (enfin, je constate que c'est c:windows).
C'est peut-être un problème lié à apache, PHP ou autre, mais peut-être
est-ce plus simplement un comportement du système qui est normal et que
je ne comprends pas. Y a-t-il une explication et une éventuelle solution
(system('cmd.exe /C cd \hostpath && commande') ne fonctionne pas) ?
Je préfère me renseigner avant de faire un rapport d'incident invalide
dans apache.
Heureusement, la configuration finale sera intégralement locale...
> Utilisez plutôt le chemin UNC (nommachinenompartage...), Ça fonctionne à merveille.
Pour info, apache démarre et trouve ses fichiers distants. PHP est en module, et trouve ses fichiers également.
En revanche, une commande système exécutée par la fonction PHP system() ne trouve pas ses fichiers. En exécutant un simple "cd" via system(), je remarque que, lorsque apache est lancé dans l'environnement utilisateur interactif, depuis un shell et dans un répertoire quelconque, system s'exécute toujours dans le répertoire attendu (celui du script, soit z:chemin).
Lorsqu'apache est lancé en tant que service, le répertoire est toujours %SYSTEMROOT% (enfin, je constate que c'est c:windows).
C'est peut-être un problème lié à apache, PHP ou autre, mais peut-être est-ce plus simplement un comportement du système qui est normal et que je ne comprends pas. Y a-t-il une explication et une éventuelle solution (system('cmd.exe /C cd hostpath && commande') ne fonctionne pas) ?
Je préfère me renseigner avant de faire un rapport d'incident invalide dans apache.
Heureusement, la configuration finale sera intégralement locale...
merci -- Stanislas Renan http://www.volcane.fr/
Johann Dantant
"Pierre Goiffon" a écrit dans le message de news:40e431a1$0$2876$
"Johann Dantant" a écrit dans le message de news:cc15hv$of1$ > Ben oui, le mapping Z: est a priori propre à ta session utilisateur, > ce n'est pas parce que le service à la même identité qu'il a la même > session (même si avec NT4 c'est un peu bizaroide à ce niveau puisque > le noyau n'isole pas correctement les sessions services de la session > interactive).
Est-ce que vous auriez plus de détails ?
Je n'ai jamais creusé la doc à ce sujet, mais vous pouvez essayer simplement avec le remote shell du resource kit... Un utilisateur loggé en session interactive, un autre utilisateur est en remote shell depuis un PC distant. L'utilisateur distant peut monter et démonter des disques réseaux, et cela a une répercussion immédiate pour l'utilisateur interactif (par contre de mémoire je crois que les droits d'accès restaient bien isolés)... Je n'ai jamais eu la curiosité de faire la même manip sous 2000, j'espère que "l'invention" de TSE et du service d'exécution par délégation a apporté un mieux de ce côté ?
J.D.
"Pierre Goiffon" <pgoiffon@nowhere.invalid> a écrit dans le message de
news:40e431a1$0$2876$626a14ce@news.free.fr...
"Johann Dantant" <news-dot-jd@pro-dash-active-dot-fr.INVALID> a écrit
dans le message de news:cc15hv$of1$1@news-reader2.wanadoo.fr
> Ben oui, le mapping Z: est a priori propre à ta session utilisateur,
> ce n'est pas parce que le service à la même identité qu'il a la même
> session (même si avec NT4 c'est un peu bizaroide à ce niveau puisque
> le noyau n'isole pas correctement les sessions services de la session
> interactive).
Est-ce que vous auriez plus de détails ?
Je n'ai jamais creusé la doc à ce sujet, mais vous pouvez essayer simplement
avec le remote shell du resource kit... Un utilisateur loggé en session
interactive, un autre utilisateur est en remote shell depuis un PC distant.
L'utilisateur distant peut monter et démonter des disques réseaux, et cela a
une répercussion immédiate pour l'utilisateur interactif (par contre de
mémoire je crois que les droits d'accès restaient bien isolés)... Je n'ai
jamais eu la curiosité de faire la même manip sous 2000, j'espère que
"l'invention" de TSE et du service d'exécution par délégation a apporté un
mieux de ce côté ?
"Pierre Goiffon" a écrit dans le message de news:40e431a1$0$2876$
"Johann Dantant" a écrit dans le message de news:cc15hv$of1$ > Ben oui, le mapping Z: est a priori propre à ta session utilisateur, > ce n'est pas parce que le service à la même identité qu'il a la même > session (même si avec NT4 c'est un peu bizaroide à ce niveau puisque > le noyau n'isole pas correctement les sessions services de la session > interactive).
Est-ce que vous auriez plus de détails ?
Je n'ai jamais creusé la doc à ce sujet, mais vous pouvez essayer simplement avec le remote shell du resource kit... Un utilisateur loggé en session interactive, un autre utilisateur est en remote shell depuis un PC distant. L'utilisateur distant peut monter et démonter des disques réseaux, et cela a une répercussion immédiate pour l'utilisateur interactif (par contre de mémoire je crois que les droits d'accès restaient bien isolés)... Je n'ai jamais eu la curiosité de faire la même manip sous 2000, j'espère que "l'invention" de TSE et du service d'exécution par délégation a apporté un mieux de ce côté ?
J.D.
Pierre Goiffon
"Johann Dantant" a écrit dans le message de news:cc1vct$9du$
(même si avec NT4 c'est un peu bizaroide à ce niveau puisque le noyau n'isole pas correctement les sessions services de la session interactive).
Est-ce que vous auriez plus de détails ?
Je n'ai jamais creusé la doc à ce sujet, mais vous pouvez essayer simplement avec le remote shell du resource kit... Un utilisateur loggé en session interactive, un autre utilisateur est en remote shell depuis un PC distant. L'utilisateur distant peut monter et démonter des disques réseaux, et cela a une répercussion immédiate pour l'utilisateur interactif (par contre de mémoire je crois que les droits d'accès restaient bien isolés)...
Mhh, ça parait plus un bug du serveur RSH, qui était je vous le rappelle en version plus que de développement dans le res kit (et qui a ensuite été vendu séparément, j'espère que ça avait été sérieusement testé et débuggé entre temps) Jamais constaté de problèmes avec des programmes "sérieux", d'où mon étonnement.
"Johann Dantant" <news-dot-jd@pro-dash-active-dot-fr.INVALID> a écrit
dans le message de news:cc1vct$9du$1@news-reader5.wanadoo.fr
(même si avec NT4 c'est un peu bizaroide à ce niveau puisque
le noyau n'isole pas correctement les sessions services de la
session interactive).
Est-ce que vous auriez plus de détails ?
Je n'ai jamais creusé la doc à ce sujet, mais vous pouvez essayer
simplement avec le remote shell du resource kit... Un utilisateur
loggé en session interactive, un autre utilisateur est en remote
shell depuis un PC distant. L'utilisateur distant peut monter et
démonter des disques réseaux, et cela a une répercussion immédiate
pour l'utilisateur interactif (par contre de mémoire je crois que les
droits d'accès restaient bien isolés)...
Mhh, ça parait plus un bug du serveur RSH, qui était je vous le rappelle en
version plus que de développement dans le res kit (et qui a ensuite été
vendu séparément, j'espère que ça avait été sérieusement testé et débuggé
entre temps)
Jamais constaté de problèmes avec des programmes "sérieux", d'où mon
étonnement.
"Johann Dantant" a écrit dans le message de news:cc1vct$9du$
(même si avec NT4 c'est un peu bizaroide à ce niveau puisque le noyau n'isole pas correctement les sessions services de la session interactive).
Est-ce que vous auriez plus de détails ?
Je n'ai jamais creusé la doc à ce sujet, mais vous pouvez essayer simplement avec le remote shell du resource kit... Un utilisateur loggé en session interactive, un autre utilisateur est en remote shell depuis un PC distant. L'utilisateur distant peut monter et démonter des disques réseaux, et cela a une répercussion immédiate pour l'utilisateur interactif (par contre de mémoire je crois que les droits d'accès restaient bien isolés)...
Mhh, ça parait plus un bug du serveur RSH, qui était je vous le rappelle en version plus que de développement dans le res kit (et qui a ensuite été vendu séparément, j'espère que ça avait été sérieusement testé et débuggé entre temps) Jamais constaté de problèmes avec des programmes "sérieux", d'où mon étonnement.
Alain Deschamps
On Fri, 2 Jul 2004 11:04:42 +0200, "Pierre Goiffon" wrote:
"Johann Dantant" a écrit dans le message de news:cc1vct$9du$
(même si avec NT4 c'est un peu bizaroide à ce niveau puisque le noyau n'isole pas correctement les sessions services de la session interactive).
Est-ce que vous auriez plus de détails ?
Je n'ai jamais creusé la doc à ce sujet, mais vous pouvez essayer simplement avec le remote shell du resource kit... Un utilisateur loggé en session interactive, un autre utilisateur est en remote shell depuis un PC distant. L'utilisateur distant peut monter et démonter des disques réseaux, et cela a une répercussion immédiate pour l'utilisateur interactif (par contre de mémoire je crois que les droits d'accès restaient bien isolés)...
Mhh, ça parait plus un bug du serveur RSH, qui était je vous le rappelle en version plus que de développement dans le res kit (et qui a ensuite été vendu séparément, j'espère que ça avait été sérieusement testé et débuggé entre temps) Jamais constaté de problèmes avec des programmes "sérieux", d'où mon étonnement.
Le problème ne provient pas d'un bug du serveur RSH mais bien du fait qu'en dehors de TSE, il n'existe qu'un seul "global namespace" contenant, entre autre, les liens symboliques ( voir http://msdn.microsoft.com/library/en-us/termserv/termserv/kernel_object_namespaces.asp ). Dans ce cadre toute session utilisateur qui n'utilise pas son propre namespace comme avec TSE, partage ses définitions de connexions réseau ou ses lecteurs virtuels ( créés par "subst" par exemple )). J'ai eu le cas avec Baan qui crée des sessions sous le compte de l'utilisateur, et je pense que le problème doit être le même avec le serveur telnet de 2000. -- echo | tr "p-za-o" "a-z"
"Johann Dantant" <news-dot-jd@pro-dash-active-dot-fr.INVALID> a écrit
dans le message de news:cc1vct$9du$1@news-reader5.wanadoo.fr
(même si avec NT4 c'est un peu bizaroide à ce niveau puisque
le noyau n'isole pas correctement les sessions services de la
session interactive).
Est-ce que vous auriez plus de détails ?
Je n'ai jamais creusé la doc à ce sujet, mais vous pouvez essayer
simplement avec le remote shell du resource kit... Un utilisateur
loggé en session interactive, un autre utilisateur est en remote
shell depuis un PC distant. L'utilisateur distant peut monter et
démonter des disques réseaux, et cela a une répercussion immédiate
pour l'utilisateur interactif (par contre de mémoire je crois que les
droits d'accès restaient bien isolés)...
Mhh, ça parait plus un bug du serveur RSH, qui était je vous le rappelle en
version plus que de développement dans le res kit (et qui a ensuite été
vendu séparément, j'espère que ça avait été sérieusement testé et débuggé
entre temps)
Jamais constaté de problèmes avec des programmes "sérieux", d'où mon
étonnement.
Le problème ne provient pas d'un bug du serveur RSH mais bien du fait
qu'en dehors de TSE, il n'existe qu'un seul "global namespace"
contenant, entre autre, les liens symboliques ( voir
http://msdn.microsoft.com/library/en-us/termserv/termserv/kernel_object_namespaces.asp
). Dans ce cadre toute session utilisateur qui n'utilise pas son
propre namespace comme avec TSE, partage ses définitions de connexions
réseau ou ses lecteurs virtuels ( créés par "subst" par exemple )).
J'ai eu le cas avec Baan qui crée des sessions sous le compte de
l'utilisateur, et je pense que le problème doit être le même avec le
serveur telnet de 2000.
--
echo papxc.sthrwpbeh@ugtt.ug | tr "p-za-o" "a-z"
On Fri, 2 Jul 2004 11:04:42 +0200, "Pierre Goiffon" wrote:
"Johann Dantant" a écrit dans le message de news:cc1vct$9du$
(même si avec NT4 c'est un peu bizaroide à ce niveau puisque le noyau n'isole pas correctement les sessions services de la session interactive).
Est-ce que vous auriez plus de détails ?
Je n'ai jamais creusé la doc à ce sujet, mais vous pouvez essayer simplement avec le remote shell du resource kit... Un utilisateur loggé en session interactive, un autre utilisateur est en remote shell depuis un PC distant. L'utilisateur distant peut monter et démonter des disques réseaux, et cela a une répercussion immédiate pour l'utilisateur interactif (par contre de mémoire je crois que les droits d'accès restaient bien isolés)...
Mhh, ça parait plus un bug du serveur RSH, qui était je vous le rappelle en version plus que de développement dans le res kit (et qui a ensuite été vendu séparément, j'espère que ça avait été sérieusement testé et débuggé entre temps) Jamais constaté de problèmes avec des programmes "sérieux", d'où mon étonnement.
Le problème ne provient pas d'un bug du serveur RSH mais bien du fait qu'en dehors de TSE, il n'existe qu'un seul "global namespace" contenant, entre autre, les liens symboliques ( voir http://msdn.microsoft.com/library/en-us/termserv/termserv/kernel_object_namespaces.asp ). Dans ce cadre toute session utilisateur qui n'utilise pas son propre namespace comme avec TSE, partage ses définitions de connexions réseau ou ses lecteurs virtuels ( créés par "subst" par exemple )). J'ai eu le cas avec Baan qui crée des sessions sous le compte de l'utilisateur, et je pense que le problème doit être le même avec le serveur telnet de 2000. -- echo | tr "p-za-o" "a-z"
