Я прохожу курс "Операционная система Unix" и после тестов, вижу в отчете, что этот тест сдало еще 25 человек. Почему так мало, это ведь реально хороший и полезный урок. Здесь естьи теория и практичесские материалы. Сам курс написан хорошо, живым языком. И здесь я получил ответы на вопросы по Linux, которые боялся спросить. Наверное это из-за того, что в названии курса написано не Linux, а Unix и это многих отпугивает. |
Аутентификация и права доступа в UNIX
Объекты и субъекты
В UNIX роль номинального (зарегистрированного) субъекта играет пользователь. Каждому пользователю выдается (обычно - одно) входное имя (login name). Каждому входному имени соответствует единственное число, идентификатор пользователя (User IDentifier, UID). Это число и есть ярлык субъекта, которым система пользуется для определения прав доступа.
Каждый пользователь входит в одну или более групп. Группа - это образование, которое имеет собственный идентификатор группы (Group IDentifier), объединяет нескольких пользователей системы, а стало быть, соответствует понятию множественный субъект . Значит, GID - это ярлык множественного субъекта, каковых у действительного субъекта может быть более одного. Список GID субъекта однозначно соответствует его UID.
Роль действительного (работающего с объектами) субъекта играет процесс. Каждый процесс снабжен единственным UID: это идентификатор запустившего процесс пользователя. Любой процесс, порожденный некоторым процессом, наследует его UID. Таким образом, все процессы, запускаемые по желанию пользователя, будут иметь его идентификатор. UID учитываются, например, когда один процесс посылает другому сигнал. В общем случае разрешается посылать сигналы "своим" процессам (тем, что имеют такой же UID). Классическое "Я тебя породил, я тебя и убью!" иллюстрируется еще и тем, что если процесс пытается убить родителя (послав ему тот или иной сигнал), то в лучшем случае ничего не происходит, чаще умирают оба, а иногда процесс, лишившийся родителя, превращается в зомби (его приходится убивать системе).
Роль объекта в UNIX играют многие реальные объекты, в частности представленные в файловой системе: файлы, каталоги, устройства, каналы и т. п. (договоримся называть любой объект файловой системы файлом, как и в лекции 7; там, где тип объекта будет важен, мы назовем его, и тип объекта "файл" будет носить имя "обычный файл"). Каждый файл снабжен UID - идентификатором пользователя - хозяина. Вдобавок у файла есть единственный GID, определяющий группу, которой он принадлежит.
Виды доступа
На уровне файловой системы в UNIX определяется три вида доступа: чтение (read, r ), запись (write, w ) и использование (execution, x ). Право на чтение из файла дает доступ к содержащейся в нем информации, а право записи - возможность ее изменять. При каждом файле имеется список того, что с ним может делать хозяин (если совпадает UID процесса и файла), член группы (если совпадает GID) и кто угодно (если ничего не совпадает). Такой список весьма невелик (три категории субъектов по три способа доступа итого 9 записей вида "можно/нельзя", в целом чуть больше одного байта). Установленное право того или иного доступа называется атрибутом (соответственно r, w или x ).
Использование файла означает возможность запустить его на выполнение (обычно атрибут x выдается программам и командным сценариям); именно среди файлов, которые пользователю разрешено выполнять, shell ищет утилиту, с имени которой началась командная строка, а заставить выполниться файл, не имеющий атрибута x из командной строки, вообще невозможно. Право на чтение из каталога позволяет узнать только список файлов в нем (можно, например, написать cat каталог и увидеть малопонятную мешанину символов, в которой, однако, встретятся имена всех файлов в каталоге).
Но уже для нормальной работы ls необходимо право на использование каталога, которое открывает доступ к самим файлам (точнее, к их атрибутам). Именно атрибут x дает пользователю право сделать каталог текущим, посмотреть свойства файлов в нем и открывать эти файлы (если, конечно, атрибуты файлов позволяют это сделать). Получается, что в каталоге, читать из которого нельзя, а использовать можно, удастся открыть файл - при условии, что вам уже известно его имя! Этим можно воспользоваться, создавая "секретные" хранилища файлов: организовать доступный только на использование каталог с подкаталогом, скажем, " VerY V@luаbLe FileZ ". Имя, конечно, может быть любым; здесь мы использовали пробелы в начале и в конце имени, потому что пробел - самый непопулярный на этом месте символ. К слову,- часто ли мы шифр в камере хранения начинаем с цифры 0?
freebsd$ ls -al archive/" VerY V@luаbLe FileZ " total 12 drwx--x--x 2 george staff 512 Dec 4 09:58 . drwxr-xr-x 3 george staff 512 Dec 4 09:57 .. -rw-r--r-- 1 george staff 135 Dec 4 09:58 SecretFile
В этот-то подкаталог можно почти без опаски складывать ценные файлы: кроме друзей, которые узнали от вас его имя, вряд ли кто-нибудь сможет туда пробраться (еще один субъект сможет наверняка, см. далее).
Запись в каталог означает право изменять список имен файлов: переименовывать, создавать и удалять все, что в нем может содержаться. Это значит, что, имея право записи в каталог, пользователь (точнее, запущенный им процесс) может переименовать или удалить (!) оттуда любой файл, даже если ни писать в этот файл, ни читать из него он не может. В обратной ситуации, когда есть право записи в файл, а в содержащий его каталог - нет, пользователь сможет изменять содержимое и атрибуты, но не имя этого файла. Это вполне логичная схема, если учитывать, что атрибуты и содержимое файла суть свойства файлов, а атрибуты каталога и его содержимое - имена файлов - это свойство каталога (в лекции 11 говорится о том, что у файла может быть сколько угодно имен в каких угодно каталогах одной файловой системы). Приходящее на ум очевидное неудобство, связанное с таким положением дел, описано чуть ниже.