http://wiki.linuxformat.ru/wiki/index.php?action=history&feed=atom&title=LXF112%3ADrBrown2 2026-05-13T03:53:23Z История изменений этой страницы в вики MediaWiki 1.19.20+dfsg-0+deb7u3 http://wiki.linuxformat.ru/wiki/index.php?title=LXF112:DrBrown2&diff=9141&oldid=prev 2009-11-29T11:05:45Z

<p>Новая: ==Радости RWX== : Доктор рассматривает права доступа к файлу и отвечает на вопросы, которые никто бы и не ...</p> <p><b>Новая страница</b></p><div>==Радости RWX==<br /> <br /> : Доктор рассматривает права доступа к файлу и отвечает на вопросы, которые никто бы и не задал.<br /> <br /> Вы знакомы с правами доступа, не так ли? Милая троица «чтение, запись, исполнение», для «владельца, группы и остальных пользователей». Конечно, знакомы! Скажем, у нас есть такой файл:<br /> <br /> $ ls -l foo<br /> -rw-r----- 1 chris student 1550 2008-08-21 15:05 foo<br /> <br /> Мы видим, что пользователь '''chris''' может читать и записывать в<br /> файл, члены группы '''student''' могут только читать его, а у остальных<br /> пользователей вообще нет доступа. А как насчет следующего файла?<br /> <br /> $ ls -l foo<br /> -r--rw---- 1 chris student 1550 2008-08-21 15:05 foo<br /> <br /> Если '''chris''' является членом группы '''student''', может ли он писать<br /> данные в файл? Когда я задаю этот вопрос в классе, мои студенты<br /> обычно делятся на три группы: «да», «нет» и «не хочу оконфузиться, дав, возможно, неверный ответ». Верный ответ – '''нет'''. Так как '''chris''' является владельцем файла, то видит первые три бита прав доступа.<br /> Точка. Linux не говорит: «Ага, но '''chris''' – член группы '''student''', поэтому<br /> он может писать в файл». На практике этот вопрос всплывает редко –<br /> вы вряд ли увидите права доступа, в которых ограничения ослабляются<br /> слева направо.<br /> <br /> Следующий вопрос: может ли '''chris''' удалить файл (права доступа те<br /> же самые)? Раз уж я убедил всех, что '''chris''' не может писать в файл,<br /> большинство студентов в классе решили, что удалить его он тоже не<br /> может. На самом деле это не исключено – в зависимости от наличия<br /> прав на запись для каталога, откуда он пытается удалить файл. Именно<br /> так: вам не нужны права на запись для файла, чтобы его удалить, нужны только права на запись для каталога.<br /> <br /> А права на выполнение? Для двоичных скомпилированных файлов, вроде тех, что в каталоге '''/usr/bin''', они означают, что вы можете запустить команду. Права на выполнение и на чтение – разные, и для<br /> выполнения файла вам не обязательно мочь его читать. Скрипты,<br /> однако, статья особая. Пусть у меня есть скрипт '''demo'''. Имея права на<br /> чтение, запустить файл я могу несколькими способами. Во-первых,<br /> можно явно запустить новую оболочку и передать ей файл скрипта как<br /> входной параметр таким образом:<br /> <br /> $ sh demo<br /> <br /> Во-вторых, можно выполнить команды скрипта из текущей оболочки, используя команду ''source'' таким образом:<br /> <br /> $ source demo<br /> $ . demo # . - сокращенный аналог source<br /> <br /> В обоих случаях мне нужны только права на чтение (а не исполнение) скрипта. Также можно выполнить скрипт как команду, набрав его имя таким образом:<br /> <br /> $ ./demo<br /> <br /> В этом случае будет автоматически запущена новая оболочка, в которой выполнится скрипт. Для этого необходимы права на чтение и выполнение, только прав на выполнение недостаточно.<br /> <br /> Другой вопрос, вызывающий путаницу – это права доступа по отношению к каталогу. Различия между правами на чтение и исполнения для каталога четко определены, но они очень тонкие. Если у меня есть<br /> право на чтение для каталога, но нет права на исполнение, я могу просмотреть содержимое каталога, но не смогу перейти в него командой ''cd''. Если у меня есть право на исполнение, но нет права на чтение,<br /> переход в каталог командой ''cd'' разрешен, но нельзя просмотреть его<br /> содержимое, хотя, как это ни удивительно, можно обратиться к файлу<br /> по имени. Суть такова: чтобы иметь разумный доступ к каталогу, нужны<br /> как права на чтение, так и на исполнение. Только одно из этих прав без<br /> второго не имеет смысла, и, насколько я знаю, в Linux нет каталогов с<br /> такими правами.<br /> <br /> ===Sticky-бит===<br /> <br /> Наконец, о значении «sticky-бита». Этот флажок появился в Unix в середине семидесятых. Когда он установлен, ядро знает: нужно оставить сегмент кода программы в области подкачки после завершения процесса. Это увеличивает скорость последовательных выполнений программы, поскольку единственное, что нужно сделать ядру<br /> в таком случае – это переместить программу из области подкачки в<br /> память. Благодаря этому часто используемые приложения – например, редакторы – будут загружаться заметно быстрее. Хотя для своего времени эта идея была неплохой, в текущих версиях Unix данный бит<br /> для обычных файлов не установлен, а в Linux никогда и не устанавливался. Но он играет важную роль для каталогов, изменяя правила, определяющие, кто может удалять в них файлы. Если бит установлен, это может делать только владелец файла, владелец каталога или суперпользователь.<br /> <br /> [[Изображение: LXF112_47_1.jpg]]<br /> <br /> Вывод команды ''ls -l foo'' (ну, большая его часть), и что он означает.<br /> <br /> <br /> ===Linux на печати===<br /> <br /> Я бы рад снабдить вас библиографией, но на рынке литературы для системных администраторов Linux сейчас затишье. До спада в индустрии технической литературы (в 2001 году) люди покупали гораздо больше книг, и<br /> публиковать можно было все что угодно. Сегодня издатели выискивают книги с большей аудиторией, чтобы избежать финансовых потерь при публикации. Почти по определению, системные администраторы – значительно меньшая группа потребителей, чем конечные пользователи, и издатели не хотят рисковать. Из этого правила есть исключения<br /> – нишевые группы читателей-энтузиастов, более охотно покупающих книги, и издатели иногда пользуются шансом сделать что-то необычное, и хорошо делают. Но львиная доля специальных изданий просто не выживет при современном экономическом климате. Наверное, мой 800-страничный труд о портировании Linux на микроволновку пока<br /> придется отложить.</div>

Crazy Rebel