Системное программирование в среде Windows

Харт Джонсон М.

 GetSecurityDescriptorOwner(pSD, &pOwnerSid, &OwnerDefF);

 GetSecurityDescriptorGroup(pSD, &pGroupSid, &GroupDefF);

 LookupAccountSid(NULL, pOwnerSid, UsrNm, &AcctSize[0], RefDomain[0], &RefDomCnt[0], &sNamUse[0]);

 LookupAccountSid(NULL, pGroupSid, GrpNm, &AcctSize[1], RefDomain[1], &RefDomCnt[1], &sNamUse[1]);

 return PBits;

}

 

Пример:

изменение разрешений на доступ к файлу

Программа 15.5 является последней в нашем собрании функций, предназначенных для работы со средствами защиты файлов. Эта функция, ChangeFilePermissions, заменяет существующий дескриптор безопасности новым, сохраняя идентификаторы SID пользователя и группы, но создавая новый разграничительный список ACL.

Программа 15.5. ChangeFilePermissions: изменение атрибутов безопасности 

BOOL ChangeFilePermissions(DWORD fPm, LPCTSTR FNm, LPDWORD AceMsk)

/* Изменить разрешения на доступ к существующему файлу. Разрешения на доступ для группы остаются неизменными. */

{

 TCHAR UsrNm[ACCT_NAME_SIZE], GrpNm[ACCT_NAME_SIZE];

 LPSECURITY_ATTRIBUTES pSA;

 PSECURITY_DESCRIPTOR pSD = NULL;

 HANDLE hSecHeap;

 if (_taccess(FNm, 0) != 0) return FALSE;

 ReadFilePermissions(FNm, UsrNm, GrpNm);

 pSA = InitializeUnixSA(fPm, UsrNm, GrpNm, AceMsk, &hSecHeap);

 pSD = pSA->lpSecurityDescriptor;

 SetFileSecurity(FileName, DACL_SECURITY_INFORMATION, pSD);

 HeapDestroy(hSecHeap);

 return TRUE;

}

 

Комментарии по поводу разрешений на доступ к файлам

В процессе выполнения этих программ весьма интересно контролировать файловую систему через проводник Windows. Эта служебная программа не в состоянии интерпретировать АСЕ, разрешающие и запрещающие доступ, и не может отображать соответствующие разрешения. В Windows 4.0 проводник, сталкиваясь с такими АСЕ, будет генерировать исключения.

Вместе с тем, использование ACL, разрешающих и запрещающих доступ, необходимо для эмуляции семантики UNIX. Если этим пренебречь, то проводник Windows сможет обеспечить просмотр разрешений. Тогда, например, при коде защиты 0446 пользователь и члены группы смогут осуществлять запись в файл, поскольку это разрешено всем пользователям категории Everyone. В то же время, UNIX действует иначе; пользователю и членам группы эта операция будет запрещена.

Понаблюдайте также за тем, что происходит, когда вы пытаетесь создать защищенный файл на дискете или в другой FAT-системе, а также когда программа выполняется под управлением Windows 9x.

Защита объектов ядра и коммуникаций

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

работы с именованными каналами, с которыми можно обращаться во многом точно так же, как с файлами.

Защита именованных каналов

Хотя соответствующая часть кода в листинге программы 11.3 опущена, сервер, полный программный код которого находится на Web-сайте книги, предоставляет возможность защиты его именованных каналов для предотвращения доступа к ним пользователей, не обладающих необходимыми полномочиями. Необязательные параметры командной строки позволяют указать имя пользователя и групповое имя:

Server [ИмяПользователя ИмяГруппы]

Если имена пользователя и группы опущены, используются коды защиты, заданные по умолчанию. Заметьте, что для создания необязательных атрибутов защиты в полной версии программы 11.3 (которая доступна на Web-сайте) и в программе 15.6 используются методы из программы 15.3. В то же время, вместо вызова функции InitUnixSA мы теперь вызываем более простую функцию InitializeAccessOnlySA, которая обеспечивает предоставление только доступа, разрешенного элементами АСЕ, и помещает последний АСЕ, запрещающий доступ, в конец списка ACL. В программе 15.6 представлены соответствующие участки кода, которые не были отражены в листинге программы 11.3. В случае именованных каналов важное значение имеют следующие права доступа:

• FILE_GENERIC_READ

• FILE_GENERIC_WRITE

• SYNCHRONIZE (разрешает потоку ожидать освобождения канала)

Если при подключении клиента требуется предоставить все права доступа, можно просто указать уровень доступа STANDARD_RIGHTS_REQUIRED. Для получения полного доступа (дуплексного, входящего, исходящего и так далее) вам также придется воспользоваться маской 0x1FF. В сервере, представленном в программе 15.6, предусмотрена защита экземпляров его именованных каналов с использованием этих прав доступа. Доступ к каналу имеют только клиенты, запущенные на выполнение владельцем канала, хотя предоставление доступа к каналу также членам группы не вызывает никаких сложностей.

Программа 15.6. ServerNP: защита именованного канала 

/* Глава 15. ServerNP. Предусмотрена защита именованного канала.

 * Многопоточный сервер командной строки. Версия на основе

 * именованного канала.

 * Использование: Server [ИмяПользователя ИмяГруппы]. */

…

_tmain(int argc, LPTSTR argv[]) {

 …

 HANDLE hNp, hMonitor, hSrvrThread[MAXCLIENTS];

 DWORD iNp, MonitorId, ThreadId;

 DWORD AceMasks[] = /* Права доступа к именованному каналу. */

{STANDARD_RIGHTS_REQUIRED | SYNCHRONIZE | 0X1FF, 0, 0 };

 LPSECURITY_ATTRIBUTES pNPSA = NULL;

 …

 if (argc == 4) /* Необязательный параметр защиты канала. */

pNPSA = InitializeAccessOnlySA(0440, argv[1], argv[2], AceMasks, &hSecHeap);

 …