Accès fichier File.exists() et WindowsIdentity

Bonjour,

je rencontre le problème suivant en C#:
j'ai un service "ServiceAgent" qui execute une dll en c# "maDLL". Ce service tounre avec les droits du compte SYSTEM. Sur mon pc, j'ai un montage disque fait par l'utilisateur courant "user1" de M:\ vers \\Server\. Et donc logiquement, le code de maDll (via un appel à File.exists() ) ne sait pas résoudre le chemin M:\. Jusque là, c'est normal.

Là ou ca se corse, c'est que le lanceur de 'ServiceAgent' est sensé lui avoir donné des droits "user" (par un méchanisme d'impersonation, j'imagine). D'ailleurs, dans le code de "maDll", quand je regarde les valeurs de WindowsIdentity, je constate que la propriété Name me renvoie bien "user1". Est ce normal que dans ce cas File.exists() ne sache pas résoudre le mapping ? Ou bien y a t'il des actions supplémentaires à faire ?

Il y a évidemment pas mal de contournements à ce problème, mais dans un monde idéal j'adorerais que mes méthodes soient exécutés avec les bons droits :).

Dites moi si je ne suis pas assez précis.

Merci d'avance

Romain

Ce n'est pas une question de droits, mais une question de montage du lecteur réseau. Les lecteurs réseau sont définis par utilisateur. Si c'est user1 qui a mappé le lecteur réseau, il n'est pas visible pour SYSTEM... Par contre, il y a un cas particulier : si c'est SYSTEM qui mappe le lecteur, il est visible de tous les utilisateurs

OK pour les problèmes de visibilité.
Cependant, en raison de l'impersonation, j'ai récuperé pas mal de droits de user1 (c'est ce que je peux voir avec WindowsIdentity). Donc je me demandais si je ne pouvais pas aller plus loin et pouvoir voir ce montage ....

Merci d'avance

Citation:

---

Envoyé par yukafrisbee

Cependant, en raison de l'impersonation, j'ai récuperé pas mal de droits de user1 (c'est ce que je peux voir avec WindowsIdentity). Donc je me demandais si je ne pouvais pas aller plus loin et pouvoir voir ce montage ....

---

En fait c'est pas juste une question de visibilité, c'est que le montage n'existe pas dans la session utilisateur de SYSTEM... Tu pourrais le monter manuellement avec WNetAddConnection2, mais dans ce cas tous les utilisateurs auront aussi ce lecteur, ce qui n'est peut-être pas voulu.

Une autre solution est de transformer le chemin avec un lecteur réseau en chemin UNC. Tu peux trouver le chemin correspondant dans la base de registre :

Code:

---

HKEY_USERS\<SID de user1>\Network\<Lettre du lecteur>\RemotePath

---

(tu ne peux pas utiliser HKEY_CURRENT_USER, car ça correspondrait à l'utilisateur SYSTEM...)

Merci pour cette réponse, ce contournement pourrait être intéressant.

Mais désolé d'insister sur le sujet, mais mon service lancé en SYSTEM ne pourrait il pas prendre les droits et voir la même chose que le compte "user1", via Windows identity, les security token ou l'impersonation ?

Merci d'avance

Citation:

---

Envoyé par yukafrisbee

Mais désolé d'insister sur le sujet, mais mon service lancé en SYSTEM ne pourrait il pas prendre les droits et voir la même chose que le compte "user1", via Windows identity, les security token ou l'impersonation ?

---

Non, l'impersonation c'est juste une question de droits. Ca ne change rien au fait qu'un lecteur soit monté ou non dans une session donnée

OK merci, je comprends mieux.

Question connexe sur le sujet : l'impersonation est elle liée à tout un process ou juste au thread courant ?

Citation:

---

Envoyé par yukafrisbee

Question connexe sur le sujet : l'impersonation est elle liée à tout un process ou juste au thread courant ?

---

juste le thread courant

Merci pour vos réponses. En creusant je me suis rendu compte que mon problème était plus une histoire de droit d'accès au serveur distant, donc je vais creuser de ce coté là et éventuellement ouvrir un nouveau fil de discussion.

Merci

Romain