8
votes

En .NET, vérifiez que l'utilisateur actuel peut écrire sur un répertoire.

in .NET, existe-t-il un moyen simple de vérifier si l'utilisateur actuel a accès à créer un fichier dans un répertoire? Quelque chose équivalent à la fonction C ++ _Access serait idéal.

Je ne veux pas utiliser d'essai et d'erreur (créer un fichier factice, puis le supprimer): Outre l'appartement piraté, d'autres logiciels surveillent le répertoire en question pour les fichiers déposés.

Je ne veux pas utiliser System.Directorysservices: En ce qui concerne les ACL, la résolution des adhésions de groupe et la manière dont les autorisations d'adhésions de groupe interagissent par erreur et trop difficiles. Il doit y avoir une fonction Yeah-or-nay quelque part, non?

Merci d'avance!

[modifier] en tant que bonus, si cela fonctionnerait aussi pour un partage de réseau également, cela serait cool.


4 commentaires

Stackoverflow.com/a/265958/284240 Par conséquent manipulez des exceptions.


Dupliquer possible de Comment vérifier si je peux créer un fichier dans un dossier spécifique en C #?


Vérifiez cette réponse, pour le convertir dans vb.net doit être trivial ;-) Stackoverflow.com/a/130641/559144


Re: manipuler des exceptions - je suis tout à fait d'accord; Sauf que je suis chargé d'écrire un script qui garantit que le système est configuré correctement, ne protège pas une opération pouvant échouer. Je veux le faire sans faire en utilisant l'essai et l'erreur.


3 Réponses :


5
votes
FileIOPermission writePermission = new FileIOPermission(FileIOPermissionAccess.Write, filename);
if (SecurityManager.IsGranted(writePermission)){
    //write here
} else {
    //some error message
}

5 commentaires

En supposant que cela fonctionne (j'espère), une de ces réponses qui me fait uppote, uppote la question et le favori :)


A l'air super! Laissez-moi l'essayer.


Cela ne semble pas fonctionner pour moi. Pour une raison quelconque, il retourne toujours vrai. Ce doit être quelque chose que je fais mal, mais c'est si simple, je ne vois pas ce que ce serait. / Soupir ... Je l'ai marqué comme accepté, car cela me fait remarquer à la bonne API. Je dois juste y arriver, je suppose


Il semble que SecurityManager.Le Greanked ne s'applique pas aux autorisations de non-CAS, cela ne fonctionne donc pas. :(


SecurityManager.isganted () est obsolète: "'SecurityManager.isganted (ipermission)' est obsolète: 'isgranted est obsolète et sera supprimé dans une version future du .NET Framework. Veuillez utiliser la propriété Permingset. d'appdomain ou d'assemblage à la place. '"



0
votes

1 commentaires

Est-ce que cela s'applique à l'utilisateur actuel? J'ai regardé cela et cela semblait donner accès à l'ACL. Il peut dire que le groupe d'utilisateurs "FOO Managers" a accès à l'écriture d'écriture et "Bar Workers" est refusé, mais ne m'aidait pas à décider si l'utilisateur actuel est membre d'un groupe membre de l'un de ces groupes. Peut-être que je manque comment résoudre ce bit



5
votes

Vérification de la permission à l'avance est un projet dériez. Sans parler de compliqué, en cours d'exécution dans toute la liste des ACL et de calculer le jeu d'autorisations effectives.

En outre ... il n'y a pas de garantie. Juste parce que vous avez vérifié de manière proactive la permission à l'avance, cela ne signifie pas que les autorisations n'auront pas changé au moment où vous essayez de créer le fichier.

La méthode "droite" est de faire un Demande de sécurité , soit déclara avec fileiopermissionnementatribute ou impérativement, en créant une instance appropriée de fileiopermision et invoquant son demande () méthode. Si vous avez les autorisations souhaitées, l'appel à demande () réussit; Sinon, il jette un SecurityException , que vous devrez attraper et agir.

Dans mon expérience, la vérification impérative est plus facile.

Il convient également de noter que dans Windows 7, alors que vous pourriez conceptuellement avoir un accès en écriture dans le répertoire, il pourrait toujours ne pas fonctionner que si vous utilisez des autorisations élevées.


1 commentaires

Je suis entièrement d'accord. Je ne voudrais pas vérifier les autorisations pour protéger une opération pouvant échouer. Nous avons un système hérité qui comporte de nombreux logiciels qui s'exécutent sur de nombreux serveurs et sont soulevés par des problèmes d'administrateur / de configuration. Je dois écrire une application qui passe à la recherche d'erreurs de configuration, mais doit le faire passivement, sans aucune chance de filtrage d'orphelins / fichiers factices ou similaires.