Предположим, что вы администратор Xsan. Между запуском системы и первыми проблемами (внимание! в новом году наш номер не изменится — 545-21-91) вашим главным занятием будет управление правами доступа к данным на ваших томах.

В системах, в которых есть собственная служба каталогов Open Directory или Active Directory, есть требования к разделению доступа, безопасности и так далее, это управление правами заключается в выдаче прав на доступ тем, кому они действительно нужны. В системе, в которой Open Directory не используется, задача обратная — обеспечить всем одинаковый доступ ко всем файлам и папкам, чтобы никто не подходил с просьбой «расшарить» или удалить.

Вторая задача значительно сложнее. Чтобы стало понятней, как с ней справиться, я подробно опишу — откуда берутся права, как они применяются к тому Xsan и как можно управлять правами доступа Xsan в отсутствие собственного каталога LDAP. По ходу заметки я дам несколько полезных советов.

Вот первый полезный совет — немедленно прекратите читать эту заметку. Если вы подумываете о том, чтобы использовать Xsan без Open Directory — немедленно передумайте. Если вы уже используете Xsan без Open Directory — немедленно прекратите. Если у вас что-то не работает — пишите нам. Вся остальная информация в этой заметке носит чисто развлекательный, информационный характер. Поверьте, используя единый каталог пользователей, вы сэкономите огромное количество времени и сил.

Хорошо. Итак, в маленьких системах, где не требуется разделение доступа к данным, этот самый доступ должен быть одинаковым у всех. На обеспечение одинаковых прав обычно и уходит практически все свободное время администратора (чтобы сэкономить время — см. первый полезный совет). Чтобы понять, почему папку, созданную на одной монтажке, не удается удалить на другой монтажке, нужно разобраться — каким образом Xsan использует права.

Доктор, а если есть аутентификация, но нет авторизации?

Каждая современная операционная система (то есть не Mac OS 9, не Windows 98 и не Palm OS) при каждой операции с файловой системой выполняет две операции (операционная система такая операционная!) Она производит аутентификацию (то есть узнает, какой пользователь пытается выполнить операцию), а затем выясняет, имеет ли этот пользователь на это право (это авторизация).  То есть, если вы работаете под пользователем whiterabbit и хотите удалить файл /mach_kernel, система узнает, какой именно пользователь пытается удалить ее ядро (кто такой whiterabbit?), а затем проверит — можно ли этому пользователю это сделать. Если можно — ядро будет удалено, если нельзя — ядро останется на месте.

Вторая часть — проверка прав — это те самые POSIX-права и ACL, которые так знакомы и близки каждому администратору. Права POSIX устроены просто (они выглядят, например, так — rwxr-xr-x). Если whiterabbit является владельцем, к нему применяются права для владельца (первые три буквы). Если whiterabbit входит в группу владения, к нему применятся права для группы (вторая тройка букв). Если ни то, ни то — применяются последние три бита. С ACL всё сложно, и поэтому мы пока сделаем вид, что их не существует — прежде всего потому что ACL не имеют отношения к той проблеме с Xsan, которую мы решаем.

Проблема берется вот откуда — когда один пользователь будет обращаться к файлам другого пользователя, для него, скорее всего, будут действовать права для группы (вторая тройка битов), а не первая. А мы сказали выше — доступ в нашей маленькой системе должен быть одинаковым у всех.

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

Вот второй полезный совет — если рассудок и благополучие дороги вам, держитесь подальше от правки umask. Путь в обход Open Directory тернист и сложен; путь, пролегающий через правку umask, полон боли, страданий и самых темных монстров из самых черных уголков ада. Если вам предложат — правка umask или лишиться левой руки, подумайте дважды — стволовые клетки очень многообещающая технология.

502, это пудинг. Пудинг, это 502

Перед тем, как мы поговорим о UID, мы скажем вот что. Xsan — это локальная файловая система. Когда вы пользуетесь сетевыми файловыми системами (например, AFP, NFS, SMB) аутентификацию выполняет сервер, который находится между вами и данными. Вы отправляете ему логин и пароль (либо аутентифицируетесь через Kerberos) и он исполняет обе операции. Сервера, управляющие Xsan — контроллеры метаданных — помогают клиентам получить прямой доступ к дискам, на которых хранятся данные, и передают им метаданные — по сути, то, что показано на скриншоте (информацию от правах, UID, GID, метках времени и так далее). Для самого компьютера это большой и очень быстрый жесткий диск — аутентификацию на котором выполняет сама система.

Короче говоря, когда вы подключаетесь к AFP-серверу, вы можете сделать это от имени любого пользователя, о котором знает сервер — а при работе с томом Xsan вы всегда работаете с ним как локальный пользователь. Единственный способ заставить другие компьютеры знать точно, кто вы такой — использовать Open Directory (пожалуйста, остановитесь тут и подумайте минутку, насколько проще будет ваша жизнь, если вы будете использовать Open Directory). То есть компьютер, на котором работает пользователь walrus, будет писать на диск как walrus, а компьютер, на котором работает carpenter — как carpenter.

Однако компьютер не использует имена пользователей ни для чего, кроме удобства пользователей. Операционная система пользуется цифровыми идентификаторами пользователей (UID) и групп (GID). Вообще, у пользователей есть несколько разных идентификаторов. Например, универсально уникальный (UUID), который, как и все UUID, выглядит так — 84E74A75-69E3-4712-B4F5-59601A6F0DD5. Универсальность этого идентификатора в том, что он не повторяется никогда и нигде, то есть универсален не просто для данного пользователя, но и среди всех пользователей всех операционных систем, да и всех объектов, когда-либо за историю Вселенной, помеченных таким UUID. Если бы пользователи идентифицировались только так (а в Windows и в Open Directory так и происходит!), все пользователи бы отличались друг от друга везде и всегда.

Но Xsan (как все локальные файловые системы в UNIX OS) использует UID и GID — простые идентификаторы, уникальные только в пределах одной системы. При этом это локальная файловая система, к которой имеет доступ множество систем одновременно — каждая из которых по сути считает себя единственным владельцем файловой системы, и считает, что известные ему GID и UID уникальны и верны в пределах всего тома Xsan.

UID первого пользователя, созданного в системе (после первого включения компьютера) — 501. Следующего — 502. Следующего — 503. При этом все пользователи (локальные и из Open Directory) входят в группу staff, GID=20. Это значит, что есть на первом компьютере свою учетную запись завела пользователь alice, а а на втором — пользователь cheshirecat, для системы они будут одним и тем же пользователем. Но если alice села за третий компьютер, настроила его для себя, а потом завела на нем учетную запись cheshirecat, чтобы и этот пользователь мог им попользоваться — для системы эти два cheshirecat никак не связаны.

Что делать-то?

Так как все эти пользователи входят в группу staff, на них будут распространятся права группы (вторая группа битов) — это я упомянул выше, а теперь объяснил, откуда это взялось. Но это значит, что файл, принадлежащий пользователю alice на одном компьютере, может не принадлежать пользователю alice на другом компьютере. Это и вызывает все эти проблемы (со значением umask по умолчанию права у владельца и группы владения разные — но ради всего святого, не прибегайте к смене umask! вы еще молоды, вам есть ради чего жить!). Как же их решить?

Убедиться, что UID у пользователя, из-под которого работают люди, одинаковый на всех машинах. Он даже не должен одинаково называться — главное, чтобы UID был одним и тем же.

А вот третий полезный совет  — в теории, вы можете управлять правами, создав одинаковых пользователей в одинаковом порядке, добавив их в локальные, в одном порядке созданные группы. Так у вас будут группы и пользователи, которые будут иметь одинаковое значение на всех компьютерах, но при этом вы проделаете в сотни раз больше работы, чем если бы вы использовали Open Directory, а потом у вас всё сломается.

Проверить, какой у пользователя UID, можно при помощи команды id (как на скриншоте выше). Проверить, какому id принадлежит папка или файл, можно, добавив к команде ls ключ -n (как на первом скриншоте).

Чтобы изменить UID существующего пользователя, откройте System Preferences (из-под другого пользователя, разумеется) → Accounts. Щелкните по иконке значка и аутентифицируйтесь. Щелкните по имени учетной записи правой кнопкой мыши (или удерживая Ctrl) и щелкните по Advanced Options.

В появившемся диалоге вы сможете изменить UID пользователя:

После этого вам надо вернуть пользователю его домашнюю папку (в данном случае — командой sudo chown -R polumrak /Users/polumrak). Когда вы войдете под ним, для Xsan он будет пользователем с новым UID.

Если вы решили использовать Xsan без Open Directory, выберите UID и убедитесь, что он одинаковый у всех пользователей, работающих с данными. Если вам нужно что-то, хотя бы на одно движение сложней абсолютно одинакового доступа ко всему — переходите на использование Open Directory.