Программирование в сетях Windows
.pdf58 |
ЧАСТЬ I Устаревшие сетевые API |
он просто позволяет перенаправителю MSNP в Windows использовать структуру данных SMB при связи со службой сервера MSNP на удаленной рабочей станции. Структура данных SMB содержит три основных компонента: код команды, параметры команды и пользовательские данные.
Протокол SMB основан на простой модели запросов клиента и ответов сервера. Клиент перенаправителя MSNP создает структуру SMB с указанием типа запроса в поле кода команды. Если команда требует отправки данных (например, SMB-команда Write), то они прилагаются к запросу. Затем структура SMB отправляется по транспортному протоколу (например, TCP/IP) серверной службе на удаленной рабочей станции. Эта служба обрабатывает запрос клиента и возвращает ему ответную структуру SMB.
Теперь рассмотрим пример: открытие файла \\Myserver\Myshare\Sample.mp3 по сети. При этом происходит следующее.
1.Приложение направляет запрос на открытие этого файла локальной ОС с помощью API-функции CreateFile.
2.Локальная ОС определяет по UNC-имени, что этот запрос ввода-вывода адресован удаленной машине с именем \\Myserver, и передает его MUP.
3.MUP определяет, что запрос предназначен компоненту доступа MSNP, поскольку именно этот компонент обнаруживает \\Myserver путем разрешения NetBIOS-имени.
4.Запрос ввода-вывода передается перенаправителю MSNP.
5.Перенаправитель форматирует запрос на открытие файла Sample.mp3 в удаленной папке \Myshare как сообщение SMB.
6.Форматированное сообщение SMB передается по сетевому транспортному протоколу.
7.Сервер с именем \\Myserver получает SMB-запрос по сети и передает его серверной службе своего перенаправителя MSNP.
8.Серверная служба выполняет локальный запрос ввода-вывода на открытие файла Sample.mp3 в общей папке \Myshare.
9- Перенаправитель сервера форматирует ответное SMB-сообщение с информацией об успехе или неудаче локального запроса ввода-вывода на открытие файла.
10.Ответ сервера посылается по сетевому транспортному протоколу обратно клиенту.
11.Перенаправитель MSNP получает ответ SMB и передает код возврата локальной ОС.
12.Локальная ОС передает код возврата вызвавшему функцию CreateFile приложению.
Как видите, перенаправителю MSNP требуется всего несколько шагов, чтобы предоставить приложению доступ к удаленным ресурсам. Перенаправитель также управляет доступом к ресурсам, что является одной из форм сетевой безопасности.
Г Л А В А 2 меренаправитель
Безопасность
Прежде чем приступить к теме безопасности и правил доступа к ресурсам в сети, обсудим основы обеспечения безопасности на локальной машине. Windows NT и Windows 2000 позволяют управлять доступом к отдельным файлам и папкам как локально, так и по сети. При попытке приложения получить доступ к таким ресурсам ОС проверяет, имеет ли это приложение соответствующие права. Основные виды доступа — чтение, запись и выполнение. Windows NT и Windows 2000 управляют доступом на основе дескрипторов безопасности (security descriptors) и маркеров доступа (access tokens).
Дескрипторы безопасности
Все защищенные объекты обладают дескриптором безопасности, содержащим информацию о порядке доступа к объекту. Дескриптор безопасности состоит из структуры SECURITYJDESCRIPTOR и связанной с ним информации
обезопасности, включающей:
Шидентификатор безопасности (Security Identifier, SID) владельца —
определяет владельца объекта;
• SID группы — определяет основную группу, в которую входит владелец объекта;
Шизбирательный список управления доступом (Discretionary Access Control List, DACL) — указывает, кто и какой тип доступа (чтение, запись, выполнение) имеет для данного объекта;
Шсистемный список управления доступом (system access control list, SACL) — задает типы доступа к данному объекту, для которых генерируются записи в журнал аудита.
Приложения не могут напрямую изменять содержимое структуры дескриптора безопасности. Впрочем, для этого можно использовать API-интер- фейсы безопасности Win32, содержащие соответствующие функции (мы продемонстрируем, как это сделать в конце главы).
Списки и записи управления доступом
Поля DACL и SACL в дескрипторе безопасности — это списки управления доступом (access control lists, ACL), содержащие ноль или более записей управления доступом (access control entities, АСЕ). Каждая АСЕ управляет доступом или осуществляет контроль за доступом к объекту определенного пользователя или группы и содержит:
ИSID пользователя или группы, к которым применяется АСЕ;
Имаску, задающую права доступа (чтение, запись, выполнение);
*флаг, обозначающий тип АСЕ — разрешение на доступ, запрет на доступ или системный аудит.
Заметим, что системный аудит применяется только в списках SACL, а типы разрешение и запрет на доступ — в списках DACL (рис. 2-2).
|
ЧАСТЬ I |
Устаревшие сетевые API |
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SID владельца |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SID группы |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Запретить |
Разрешить |
|
|
|
|
|
|
|
||
|
DACL |
|
|
|
Разрешить |
|
||
|
|
|
|
запись для Jim |
|
чтение для |
чтение |
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
Anthony |
для NetTeam |
|
|
|
|
|
АСЕ |
АСЕ |
АСЕ |
|
|
SACL |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Дескриптор безопасности
Рис.2-2.ОбъектфайлассоответствующимемуDACL
Если защищенный объект не имеет списка DACL (его DACL был обнулен API-функцией SetSecurityDescriptorDad), то система предоставляет всем полный доступ. Если объект имеет непустой DACL, система предоставляет только те типы доступа, которые явно указаны в записях АСЕ данного DACL. Если в списке нет ни одной записи АСЕ, система не предоставляет никому никакого доступа. Если же DACL содержит несколько разрешающих доступ записей АСЕ, система неявно запрещает доступ всем пользователям и группам, не включенным в список.
В большинстве случаев задают только разрешающие доступ записи АСЕ, за одним исключением: если имеется разрешающая запись для группы, но нужно запретить доступ каким-либо членам этой группы с помощью АСЕ. При этом запрещающая доступ запись АСЕ должна обязательно предшествовать записи, открывающей доступ всей группе, поскольку система читает записи по порядку и прекращает чтение, выяснив, что доступ данному пользователю открыт или закрыт. То есть если запись, разрешающая доступ группе, будет идти первой, система прочтет ее и предоставит доступ неполномочному пользователю из состава группы.
На рис. 2-2 показан список DACL, предоставляющий доступ для чтения группе Net Team. Эта группа состоит из пользователей Anthony, Jim и Gary, и нужно предоставить право чтения всем, кроме Anthony. Поэтому запись, запрещающая доступ пользователю Anthony, предшествует записи, разрешающей доступ группе Net Team На рис. 2-2 также показана запись АСЕ, предоставляющая пользователю Jim доступ для записи. Напомним, что приложения не могут напрямую работать с АСЕ, а используют для этого специальные APIинтерфейсы.
Идентификаторы безопасности
Дескрипторы безопасности и записи АСЕ защищенных объектов содержат SID — уникальный код для идентификации учетной записи пользователя,
Г Л А ВА 2 Перенаправитель |
Ы |
группы или сеанса. Центр безопасности (например, домен Windows NT) хранит информацию о SID в специальной базе данных Когда пользователь входит в систему, его SID извлекается из БД, помещается в маркер доступа пользователя и применяется для идентификации пользователя при всех проверках безопасности.
Маркерыдоступа
При входе пользователя в систему Windows NT проверяются его реквизиты: имя учетной записи и пароль. Если вход разрешен, система создает маркер доступа и заносит в него SID пользователя. Каждый процесс, запущенный от имени этого пользователя, получит копию маркера. При попытке доступа процесса к защищенному объекту SID в маркере доступа сравнивается с SID в списках DACL для определения прав доступа.
Сетевая безопасность
Рассмотрим теперь обеспечение безопасности при доступе к объектам по сети. Напомним, что за доступ к ресурсам на удаленных компьютерах отвечает перенаправитель MSNP. Для этого он устанавливает безопасное соединение клиент-сервер, создавая реквизиты сеанса пользователя.
Реквизиты сеанса
Существуют реквизиты пользователя двух типов: основныереквизиты входа (primary login) и реквизиты сеанса. Когда пользователь регистрируется на рабочей станции, вводимые им имя и пароль становятся его основными реквизитами входа и заносятся в маркер доступа. В один момент времени пользователь может иметь единственный набор реквизитов. При попытке доступа к удаленному ресурсу (как через сетевой диск, так и по UNC-имени) пользовательские реквизиты входа используются для проверки прав доступа к этому объекту.
В Windows NT и Windows 2000 можно указать другой набор реквизитов для удаленного доступа по сети. Если реквизиты пользователя действительны, перенаправитель MSNP создает сеанс связи между компьютером пользователя и удаленным ресурсом. При этом он сопоставляет сеансу реквизиты, состоящие из копии реквизитов, примененных компьютером пользователя для доступа к ресурсу. При каждом сеансе связи между компьютером и удаленным сервером используется только один набор реквизитов. Например, если на машине В имеются общие папки \Hack и \Slash, и пользователь с машины А подключает папку \Hack как диск G:, а папку \Slash — как диск Н:, то оба сеанса связи будут применять одинаковые реквизиты сеанса, так как устанавливают соединение с одним и тем же удаленным сервером
На удаленном сервере безопасность контролирует серверная служба перенаправителя MSNP. При попытке получить доступ к защищенному объекту, она использует реквизиты сеанса для создания маркера удаленного доступа. Далее безопасность обеспечивается так же, как и при локальном доступе (рис. 2-3)-
1. Пользователь входит |
|
|
на рабочую станцию А |
|
|
с реквизитами для |
Контроллер |
|
домена Windows NT |
|
|
домена |
|
|
|
|
|
|
|
5 Серверная служба |
|
2. Пользовательские |
перенаправителя на |
|
удаленной системе |
|
|
реквизиты входа проверяются |
|
|
проверяет реквизиты |
|
|
контроллером домена |
|
|
сеанса на контроллере |
|
|
Windows NT |
|
|
домена |
|
|
|
Рабочая станция А
3. Пользователь запрашивает открытие файла по UNC-соединению
на рабочей станции В
4 Перенаправитель |
Рабочая станция В |
||
|
|
||
MSNP устанавливает |
|
|
|
сеанс на основе реквизитов, |
6. Удаленная система |
||
полученных на шаге 1 |
|
||
|
обслуживает UNC-запрос |
||
(или специальных реквизитов |
|||
|
|||
для удаленного доступа, |
|
|
|
предоставленных Windows NT |
|
||
или Windows 2000) |
|
|
|
Рис. 2-3. Применение реквизитов безопасности
Пример
Приложения Win32 могут использовать API-функции CreateFile, ReadFile и WriteFile для создания, открытия и изменения файлов по сети с использованием перенаправителя MSNP. Заметьте, что только платформы Windows NT и Windows 2000 поддерживают модель безопасности Win32. В листинге 2-1 приведен пример кода приложения, создающего файл по UNC-соединению. Вы можете найти его в папке \Examples\Chapter02 на прилагаемом компактдиске.
Листинг 2-1. Простой пример создания файла
«include <windows.h> ((include <stdio.h>
void main(void)
HANDLE FileHandle;
DWORDBytesWritten;
// Открытие файла \\Myserver\Myshare\Sample.txt
if ((FileHandle = CreateFile("\\\\Myserver\\Myshare\\Sample.txt", GENERIC_WRITE | GENERIC.READ,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL)) == INVALID_HANDLE_VALUE)
printf("CreateFile failed with error Xd\n", GetLastErrorO); return;
Г Л А ВА 2 Перенаправитель |
63 |
Листинг 2-1. (продолжение)
II Запись 14 байт в новый файл
if (WriteFile(FileHandle, "This is a test", 14, &BytesWritten, NULL) == 0)
{
printf("WriteFile failed with error Xd\n", GetLastError()); return;
if (CloseHandle(FileHandle) == 0)
{
printf("CloseHandle failed with error Xd\n", GetLastErrorO); return;
Резюме
В этой главе вы познакомились с перенаправителем Windows, позволяющим приложениям получать доступ к ресурсам файловой системы Windows по сети. Мы рассказали, как он осуществляет обмен информацией по сети и как при этом используется система безопасности Windows NT и Windows 2000.
Две следующие главы посвящены технологиям почтовых ящиков и именованных каналов, опирающихся на перенаправитель для выполнения любых действий по сети.
At
-А„
Г Л А В А
Почтовыеящики
В Microsoft Windows NT, Windows 2000, Windows 95 и Windows 98 (но не Windows СЕ) реализован простой однонаправленный механизм межпроцессной связи (interprocess communication, IPC), называемый почтовыми ящиками (mailslots). Почтовые ящики позволяют клиентскому процессу передавать сообщения одному или нескольким серверным процессам. Они также помогают передавать сообщения между процессами на одном и том же компьютере или на разных компьютерах в сети. Разработка приложений, использующих почтовые ящики, не требует знания сетевых транспортных протоколов, таких как TCP/IP или IPX. Поскольку почтовые ящики основаны на архитектуре широковещания, они не гарантируют надежной передачи данных, но полезны, когда доставка данных не является жизненно важной.
Один из таких случаев — создание системы сообщений, охватывающей всех сотрудников офиса. Допустим, в офисе с множеством рабочих станций не хватает газированной воды, и все пользователи хотят каждые несколько минут знать, сколько банок кока-колы осталось в автомате. Легко установить клиентское приложение, отслеживающее количество банок и передающее эту информацию всем заинтересованным пользователям каждые пять минут. Поскольку почтовые ящики не гарантируют доставку широковещательного сообщения, некоторые пользователи могут не получить всех обновлений информации. Но несколько неудачных передач не приведут к неприятностям, потому что информация обновляется достаточно часто.
Итак, основное ограничение почтовых ящиков: они допускают только ненадежную однонаправленную передачу данных от клиента к серверу. Основное преимущество: клиентские приложения могут легко посылать широковещательные сообщения одному или нескольким серверным приложениям.
В этой главе мы расскажем о создании клиент-серверного приложения, правилах именования почтовых ящиков, влиянии размера сообщений на работу почтовых ящиков, связанных с ними проблемах и ограничениях.
Подробности внедрения почтовых ящиков
Почтовые ящики основаны на интерфейсе файловой системы Windows. Клиентское и серверное приложения используют стандартные функции вводавывода файловой системы Win32 (такие как ReadFtte и WriteFile) для отправки и получения данных почтовым ящиком, а также правила именования фай-
Г Л А ВА 3 Почтовые ящики |
65 |
ловой системы Win32. Для создания и идентификации почтовых ящиков перенаправитель Windows использует файловую систему Mailslot File System (MSFS). Подробнее о перенаправителе Windows — в главе 2.
Именапочтовыхящиков
Почтовые ящики именуются по следующему правилу: \\cepsep\Mailslot\[путь]имя
Строка состоит из трех частей: \\server, \Mailslot и \[path]name, где \\cepвер — имя сервера, на котором создается почтовый ящик и выполняется серверное приложение; \Mailslot — фиксированная обязательная строка, уведомляющая систему, что это имя файла относится к MSFS; \[путь]имя — позволяет приложениям уникальным образом определять и идентифицировать имя почтового ящика. В строке путь разрешается задавать несколько уровней каталогов. Например, допустимы следующие типы имен почтовых ящиков:
\\Oreo\Mailslot\Mymailslot
\\Testserver\Mailslot\Cooldirectory\Funtest\Anothermailslot
\\.\Mailslot\Easymailslot
\\*\Mailslot\Myslot
Строка сервер может представлять собой точку (.), звездочку (*), имя домена или сервера. Домен — это группа рабочих станций и серверов с общим групповым именем. Об именах почтовых ящиков мы расскажем далее в этой главе, когда будем подробно обсуждать реализацию простого клиента.
Поскольку для создания и передачи данных по сети почтовые ящики используют службы файловой системы Windows, их интерфейсный протокол независим. При создании приложения, процессы которого взаимодействуют по сети, не нужно знать, как работают нижележащие сетевые транспортные протоколы. Когда почтовые ящики устанавливают удаленное соединение с компьютерами в сети, для передачи данных от клиента к серверу перенаправитель Windows использует протокол Server Message Block (SMB). Сообщения обычно пересылаются без установления соединения, но в зависимости от размера сообщения вы можете заставить перенаправитель Windows устанавливать соединения на компьютерах с Windows NT или Windows 2000.
Размеры сообщений
Для передачи сообщений по сети почтовые ящики обычно используют дейтаграммы (datagram) — небольшие порции данных, передаваемые по сети без установления соединения. Это ненадежный способ, поскольку уведомление о получении пакета данных не пересылается, и его доставка не гарантируется. Между тем, с помощью дейтаграмм можно передавать сообщения от одного клиента многим серверам. Этот механизм не работает на компьютерах с Windows NT и Windows 2000, если размер сообщения превышает 424 байта.
66 ЧАСТЬ I Устаревшие сетевые API
На компьютерах с Windows NT и Windows 2000 сообщения размером более 426 байт передаются с использованием протокола, требующего установления соединения в сеансе SMB, а не дейтаграммами. Это позволяет передавать большие сообщения надежно и эффективно. Впрочем, в этом случае вы теряете возможность передавать сообщение от одного клиента многим серверам. При установлении соединения допускается соединение только одного клиента с одним сервером и гарантируется доставка данных между процессами.
Однако интерфейс почтового ящика в Windows NT и Windows 2000 не гарантирует, что сообщение будет действительно записано в почтовый ящик. Например, если вы посылаете большое сообщение от клиента несуществующему серверу, интерфейс почтового ящика не сообщит клиентскому приложению, что не смог передать данные.
Поскольку Windows NT и Windows 2000 выбирают способ передачи в зависимости от размера сообщения, появляется проблема совместимости при передаче больших сообщений между компьютером с Windows NT или Windows 2000 и компьютером с Windows 95 или Windows 98.
Windows 95 и Windows 98 доставляют сообщения только посредством дейтаграмм, независимо от их размеров. Если клиент Windows 95 или Windows 98 попытается отправить сообщение больше 424 байт серверу Windows NT или Windows 2000, последний примет первые 424 байта и отбросит остальные, поскольку принимает большие сообщения в сеансе SMB с установлением соединения. Похожая проблема существует при передаче сообщений от клиента Windows NT или Windows 2000 серверу Windows 95 или Windows 98. Помните: Windows 95 и Windows 98 получают данные только посредством дейтаграмм. Поскольку Windows NT и Windows 2000 передают дейтаграммами только сообщения размером не более 426 байт, Windows 95 и Windows 98 не получат от таких клиентов сообщений большего размера (табл. 3-1)-
Табл. 3-1. Ограничения размера сообщений почтовых ящиков
Направление
передачи
Windows 95 или Windows 98
-> Windows 95 или Windows 98
Windows NT или Windows 2000 -> Windows NT
или Windows 2000
Windows NT или Windows 2000 -> Windows 95 или Windows 98
Windows 95 или Windows 98
-> Windows NT или Windows 2000
Передача посредством |
Передача с установлением |
|
дейтаграмм без установления соединения |
|
|
соединения |
|
|
Размер сообщения |
Не поддерживается |
|
не более 64 кб |
|
|
Размер сообщения |
Сообщения должны быть |
|
не более 424 байт |
более 426 байт |
|
Размер сообщения |
Не поддерживается |
V.f |
|
||
не более 424 байт |
|
|
Размер сообщения не более |
Не поддерживается |
|
424 байт, иначе сообщение |
|
|
усекается до этого размера |
|
|
Г Л А ВА 3 Почтовые ящики |
67 |
ПРИМЕЧАНИЕ Windows СЕ не описана в табл. 3-1, потому что в этой ОС интерфейс программирования почтовых ящиков не доступен. Сообщения размером 425—426 байт также не описаны в таблице, из-за ограничений перенаправителей Windows NT и Windows 2000.
Перенаправители Windows NT и Windows 2000 не могут отправлять или принимать дейтаграммы размером 425—426 байт. Например, если вы отправляете от клиента Windows NT или Windows 2000 сообщение серверу Windows 95, Windows 98, Windows NT или Windows 2000, перед его отправкой серверу перенаправитель Windows NT усекает сообщение до 424 байт.
Чтобы обеспечить полную совместимость всех платформ Windows, ограничте размер сообщений 424 байтами. При установлении соединений воспользуйтесь вместо почтовых ящиков именованными каналами.
Компиляция приложения
При сборке клиента или сервера почтовых ящиков в Microsoft Visual C++ необходимо включать в программные файлы приложений заголовочный файл Winbase.h. Если вы включаете файл Windows.h (как в большинстве приложений), Winbase.h можно опустить. Ваше приложение также должно компоноваться с библиотекой Kernel32.1ib, соответствующие параметры обычно настраивают с помощью флагов компоновщика Visual C++.
Кодыошибок
Все API-функции Win32, используемые при разработке клиентов и серверов почтовых ящиков (за исключением CreateFile и CreateMailslof), в случае неудачи возвращают 0. API-функции CreateFile и CreateMailslot возвращают значение INVALID_HANDLE_VALUE. Для получения кодов ошибок этих функций, приложение должно вызывать функцию GetLastError. Полный список кодов ошибок см. в приложении С или в файле Winerror.h.
Общие сведения об архитектуре клиент-сервер
Почтовые ящики используют простую архитектуру клиент-сервер, в которой данные передаются от клиента серверу однонаправленно. Сервер отвечает за создание почтового ящика и является единственным процессом, который может читать из него данные. Клиенты почтовых ящиков — это процессы, открывающие экземпляры почтовых ящиков и единственные, имеющие право записывать в них данные.
Серверпочтовыхящиков
Для реализации почтового ящика нужно написать базовое серверное приложение, в котором выполнить следующие действия.
• Создать описатель почтового ящика с помощью API-функции CreateMailslot. Получить данные от любого клиента путем вызова API-функции ReadFile с описателем почтового ящика в качестве параметра.
Закрыть описатель почтового ящика с помощью API-функции CloseHandle.