C# .NET - jak ustalić, czy katalog jest zapisywalny, z UAC lub bez niego?

Question

Pracuję nad oprogramowaniem, które musi skopiować plik do podanego katalogu w systemie plików. Musi działać zarówno w systemach operacyjnych UAC-owych (Vista, 7), jak i XP. Aby obejść problem pisania do katalogu, w którym wymagane jest podniesienie UAC, aplikacja faktycznie uruchamia inny proces z manifestem, który stwierdza, że ​​ZAK jest wymagany. Spowoduje to wygenerowanie monitu, a następnie wykonanie kopii po potwierdzeniu przez użytkownika.

Z tego co widzę, katalog może mieć trzy różne stany uprawnień logicznych - możliwe do zapisania bez podniesienia UAC, możliwe do zapisania z podniesieniem UAC i niepisywalne.

Moje pytanie brzmi: w przypadku danego katalogu, w jaki sposób można wiarygodnie ustalić, czy bieżący użytkownik może skopiować (i potencjalnie nadpisać) plik do tego katalogu, a jeśli mogę, w jaki sposób określić, czy wymagane jest podniesienie UAC ?

W przypadku XP może to być tak proste, jak sprawdzenie, czy zezwolenie "Zezwalaj na zapisywanie" jest przyznane, ale w systemie Vista/7 istnieją katalogi, w których to uprawnienie nie jest przyznane, ale ta akcja jest nadal możliwa w przypadku UAC .

Answer 1

Mamy metodę WriteAccess na plikach, prawdopodobnie można ją dostosować do katalogów (Directory.GetAccessControl i tak dalej)

/// <summary> Checks for write access for the given file. 
    /// </summary> 
    /// <param name="fileName">The filename.</param> 
    /// <returns>true, if write access is allowed, otherwise false</returns> 
    public static bool WriteAccess(string fileName) 
    { 
     if ((File.GetAttributes(fileName) & FileAttributes.ReadOnly) != 0) 
      return false; 

     // Get the access rules of the specified files (user groups and user names that have access to the file) 
     var rules = File.GetAccessControl(fileName).GetAccessRules(true, true, typeof(System.Security.Principal.SecurityIdentifier)); 

     // Get the identity of the current user and the groups that the user is in. 
     var groups = WindowsIdentity.GetCurrent().Groups; 
     string sidCurrentUser = WindowsIdentity.GetCurrent().User.Value; 

     // Check if writing to the file is explicitly denied for this user or a group the user is in. 
     if (rules.OfType<FileSystemAccessRule>().Any(r => (groups.Contains(r.IdentityReference) || r.IdentityReference.Value == sidCurrentUser) && r.AccessControlType == AccessControlType.Deny && (r.FileSystemRights & FileSystemRights.WriteData) == FileSystemRights.WriteData)) 
      return false; 

     // Check if writing is allowed 
     return rules.OfType<FileSystemAccessRule>().Any(r => (groups.Contains(r.IdentityReference) || r.IdentityReference.Value == sidCurrentUser) && r.AccessControlType == AccessControlType.Allow && (r.FileSystemRights & FileSystemRights.WriteData) == FileSystemRights.WriteData); 
    } 

nadzieję, że to pomaga.

Answer 2

Obsługujesz zapisywalną skrzynkę bez podniesienia wysokości, wykonując operację. Dzieje się tak, gdy się to nie udaje, i trzeba rozróżnić między nieopisywalnym a zapisywalnym przez elewację UAC, co jest potencjalnie trudne.

Nie sądzę, że chciałbym, żeby programy próbowały mi to rozgryźć (ponieważ nieuchronnie często będą się mylą).

myślę, że to bezpieczne, aby zaprojektować go z tych założeń:

• Administratorzy czasami działać jako ograniczonych kont do oprogramowania próbnego nie ufa -> jeśli aplikacja ma zamiar zrobić inwazyjnych zmian w komputerze wymagają UAC, który chcą anulować, a nie podnosić.
• Podwyższeni administratorzy mogą zapisać plik (w końcu są administratorem) -> nie ma potrzeby faktycznego sprawdzania listy ACL, wystarczy wykryć ograniczony token.
• Użytkownicy mogą podnosić poziom konta przy użyciu innego konta lub mogą poprosić współpracownika o wykonanie czynności wymaganych do kontroli konta użytkownika -> sprawdzenie, czy token ograniczony nie przeoczy tych przypadków.
• Inne rzeczy do odzyskania powodują odmowę dostępu, w tym plik w użyciu -> czasem właściwym rozwiązaniem jest ponowienie próby z użyciem tych samych ograniczonych uprawnień.

Więc w sumie, proponuję spróbować AsInvoker operacji, w przypadku dostępu odmówiono przywołać wiersz, który wyjaśnia, że ​​Windows odmawia operacji, możliwe przyczyny to: plik w użyciu, wymaga elewacja wymagane poświadczenia administratora i daje użytkownikowi trzy przyciski:

• Anuluj
• ponów aktualnych poświadczeń
• (ikonę tarczy) Elevate uprawnienia i ponów