C#.NET-¿cómo determinar si el directorio es grabable, con o sin UAC?

permissions

Question

Estoy trabajando en una pieza de software que necesita copiar un archivo a un directorio determinado en el sistema de archivos. Debe funcionar tanto en sistemas operativos con reconocimiento de UAC (Vista, 7) como en XP. Para evitar el problema de escribir en un directorio donde se requiere la elevación de UAC, la aplicación realmente inicia otro proceso con un manifiesto que establece que se requiere UAC. Esto genera el mensaje y luego hace la copia cuando el usuario confirma.

Por lo que puedo ver, un directorio puede tener tres estados de permisos lógicos diferentes: grabable sin elevación UAC, escribible con elevación UAC y no grabable.

Mi pregunta es la siguiente: para un directorio determinado, ¿cómo puedo determinar de manera confiable si el usuario actual puede copiar (y posiblemente sobreescribir) un archivo en ese directorio, y si puedo, cómo puedo determinar si es necesaria la elevación del UAC?

En XP, esto podría ser tan simple como verificar si se concede el permiso ''Permitir escritura'', pero en Vista / 7, hay directorios en los que no se concede este permiso, pero esta acción aún es posible con UAC.

Answer 1

Tenemos un método para WriteAccess en archivos, probablemente puede adaptarlo para Directorios (Directory.GetAccessControl, etc.)

    /// <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);
    }

Espero que esto ayude.

Answer 2

Usted maneja la capacidad de escritura sin elevación solo con solo probar la operación. Es cuando eso falla, y usted tiene que distinguir entre escritura no grabable y escritura a través de la elevación UAC que es potencialmente difícil.

No creo que me gustaría que los programas intenten darme cuenta (ya que inevitablemente se equivocarán con bastante frecuencia).

Creo que es seguro diseñarlo con estas suposiciones:

• Los administradores a veces se ejecutan como cuentas restringidas para probar el software en el que no confían -> si su aplicación va a realizar cambios invasivos en la computadora que requieren UAC que desean cancelar, no elevar.
• Los administradores elevados pueden escribir el archivo (son administradores después de todo) -> no es necesario realizar una verificación de ACL real, detectar un token restringido es suficiente.
• Los usuarios pueden elevar usando una cuenta diferente, o pueden pedirle a un compañero de trabajo que complete la acción requerida por UAC -> al buscar el token restringido se perderán estos casos.
• Otras cosas recuperables provocan el acceso denegado, incluido el archivo en uso -> a veces lo correcto es volver a intentarlo con los mismos permisos restringidos.

Así que, en conjunto, sugeriría probar la operación AsInvoker, en caso de acceso denegado mostrar un aviso que explique que Windows negó la operación, las posibles causas son: uso de archivos, elevación requerida, credenciales de administrador requeridas, y dar al usuario tres botones:

• Cancelar
• Reintentar con las credenciales actuales
• (icono de escudo) Eleva los permisos y vuelve a intentar