Как Windows разрешает конфликтующие права/права на FileSystem?

Question

В системе безопасности Windows пользователь может принадлежать многим группам, а группа может содержать другие группы. Каковы «правила» разрешения конфликтов в Windows?

Например, пользователь находится в группе A, а также в группе B. Группа A имеет «Запретить чтение» в файле, а «Группа B» имеет «Разрешить чтение». Может ли пользователь прочитать файл?

Что делать, если пользователю было отказано в правах на чтение чего-либо, но оно находится в группе, где это разрешение явно разрешено?

Хотя я знаю, как получить разрешения для определенного ресурса FileSystem через AccessRules и права, которые они раскрывают, поскольку правила нацелены на определенный IdentityReference, который может быть пользователем или группой, я видел конфликты и пытаюсь определить логику, чтобы выяснить, кто победит.

... или есть известный способ сказать: «Получите мне все права для этого пользователя, также принимая во внимание любые членства», и пусть система беспокоится об этом? (.. Я удивлен, что я не нашел точно, что уже что я делаю кажется ужасно много работы)

var Identity = WindowsIdentity.GetCurrent(); 
var fileInfo = new FileInfo(@"C:\Code\Path\To\Some\File.txt"); 

// Get all identity references for this user (user's and it's groups) 
var identityReferences = new HashSet<IdentityReference>(); 
identityReferences.Add(Identity.User); 
foreach(var group in Identity.Groups) 
    identityReferences.Add(group); 

// Get all rules for this user on this specific FileInfo 
var fileSystemAccessRules = fileInfo.GetAccessControl() 
    .GetAccessRules(true, true, typeof(SecurityIdentifier)) 
    .OfType<FileSystemAccessRule>() 
    .Where(rule => identityReferences.Contains(rule.IdentityReference)); 

FileSystemRights allowedUserRightsMask = 0; 
FileSystemRights deniedUserRightsMask = 0; 

// Get mask of all granted, and all denied rules 
foreach(var fileSystemAccessRule in fileSystemAccessRules) 
{ 
    var ruleRights = fileSystemAccessRule.FileSystemRights; 

    var relevantUserRightsMask = (fileSystemAccessRule.AccessControlType == AccessControlType.Allow) 
     ? allowedUserRightsMask 
     : deniedUserRightsMask; 

    relevantUserRightsMask |= ruleRights; 
} 

// Do something with the final user rights mask here. 

Answer 1

Приоритет определяется порядком АСЯ, как описан в странном имени How AccessCheck Works в MSDN:

Система не проверяет каждый ACE в последовательности, пока один из следующих событий:

ACE с запретом доступа явно отказывает в любом запрошенном праве доступа одному из доверенных лиц, указанному в токене доступа потока.

Один или несколько разрешенных ACE для доверенных лиц, перечисленных в токене доступа к потоку, явно предоставляют все запрашиваемые права доступа.

Все проверки ACE были проверены, и по-прежнему существует хотя бы одно запрошенное право доступа, которое явно не разрешено, и в этом случае доступ неявно отклоняется.

Существует также стандартный порядок, в котором должны присутствовать ACE в DACL, как описано в Order of ACEs in a DACL. Если разрешения были установлены встроенными инструментами Windows, ACE будут в этом порядке, то есть как вы получите правила, описанные Эстебаном в его ответе (see referenced article). Обратите внимание, однако, что DACL не имеют, чтобы следовать этому стандарту. Приложения могут устанавливать DACL, который этого не делает, хотя обычно это неразумно делать, потому что это смущает графический интерфейс Windows.

(Обратите внимание, что некоторые API могут автоматически переупорядочить ACE в ACL стандартным порядком, если вам нужно сохранить фактический порядок ACE в ACL, убедитесь, что вы используете API, который этого не делает.)

Усложняет дело, есть также дополнительные правила, такие, как тот факт, что владелец объекта имеет READ_CONTROL и WRITE_DAC неявно предоставляется, и что существуют дополнительные доверенные лица, такие как INTERACTIVE в типичном маркер доступа, не относящийся к группе членство.

Как правило, правильное поведение не, чтобы попытаться определить, какие права доступа у вас есть, а просто попытаться выполнить любое действие, которое вы хотите предпринять, и обработать ошибку, если она не удалась. (В частности, имейте в виду, что доступ к файлу может завершиться не по причине, отличной от прав доступа, например, потому что файл используется другим процессом.)

Однако, в редких случаях, когда вам действительно нужно для определения соответствующих прав доступа вы можете сделать это, используя функцию AuthzAccessCheck(). Пример кода доступен в документации по функции (устаревшая и неточная) GetEffectiveRightsFromAcl().

(я не достаточно хорошо знаком с .NET, чтобы убедиться, содержит ли он встроенный эквивалент;. Я думаю, что это не Тем не менее, вы можете P/Invoke, если это необходимо.)

Answer 2

Как указано в Understanding Windows NTFS Permissions разрешения старшинства выглядит следующим образом:

1. Явные Запретить
2. Явные Разрешить
3. Наследуется Запретить
4. Наследуется Разрешить

Итак, чтобы ответить на ваш вопрос: это зависит. Явный отказ всегда имеет приоритет; унаследованный запрет, однако, «теряет» до явного разрешения.

См. Статью для получения более подробной информации о последствиях этого.