ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Ramazan Jah-Far                      2:5020/400     22 Jun 2004  00:01:11
 To : Victor Wagner
 Subject : Re: symlinks vs. hardlinks
 -------------------------------------------------------------------------------- 
 

 Hi!
 In fido7.ru.linux, Victor Wagner wrote:
 
  RJF>> Здесть есть динамика (управление) и статика (состояние ФС на
  RJF>> некий момент). Если отделить первое от второго, получим
  RJF>> бездыханный труп (ФС), которому BTW для _хранения_
  RJF>> информации нафиг не нужны директории, права доступа и прочая
  RJF>> "файловая система"-тичность. :)
  VW> Я тебя опровергну одним маленьким примером. Представь себе файловую
  VW> систему iso9660 - где там динамика?
 
 Дело в том, что под динамикой я имел в виду не изменение ФС,
 а просто активное её использование.
 
 Это твоя же мысль про связь "структура<->задачи", только
 другими словами. Смысл в том, что cтруктура нужна не сама по
 себе.
 
  VW>>> Второе ограничение - отсутствие некоей классификации дуг.
  RJF>> А зачем? // Лучше на примере.
  VW> Hа примере. Берем почти вырожденный пример - реплика в web-форуме.
  VW> Она связана
  VW> 1. Со своим автором (которому соответствует скорее всего какой-нибудь
  VW> объект в системе. Ведь должен же юзер как-то авторизовываться)
  VW> 2. С репликой, в ответ на которую она дана.
  VW> 3. С чем-то что послужило завязкой данной дискуссии.
  VW>
  VW> Со статьей опубликованной на сайте всё еще сложнее. У нее кроме связей
  VW> типа "Автор" и "рубрика" может быть связь "Переводчик", если она
  VW> переводная, связь "Редактор", связь "в ответ на эту статью поступила" с
  VW> репликой в форуме, и связь "См. также" с другими статьями, на которые
  VW> ссылается автор работы (вживую всё это можно увидеть на
  VW> www.libertarium.ru или любом другом сайте на движке Communiware).
 
 Это мне напоминает организацию базы знаний (вот, опять
 не помню правильный термин).
 
 Это, конечно-же, хорошо, но для ФС, по моему глубокому
 убеждению, overkill.
 
  RJF>> Пользователь -- далеко не единственный пользователь ФС,
  RJF>> есть ещё ОС и ПО.
  VW> Мы тут вели речь о той абстракции, которая видима пользователю. О том
  VW> чем там внутри пользуются ОС и ПО - разговор отдельный.
 
 Опять же, я пока говорю об организации ФС на уровне
 "максимальной видимости", т.е. на том уровне, на котором с
 ней работает OS/VFS/FS-driver.
 С этой высоты FS односвязна или, иными словами, прозрачна
 для OS/VFS/FS-driver. И отсюда должны быть видны и доступны
 те особенности её структуры, которые обеспечивают разделение
 её на видимые пользователям домены.
 
  VW> Хотя в рамках unix-way ПОЛЬЗОВАТЕЛЬСКОЕ ПО должно видеть
  VW> ту же самую картину, что и пользователь
 
 Вообще, да.
 
  RJF>> Смысл в том, что злонамеренный пользователь откладывает (ln)
  RJF>> suid-ные бинари впрок для осуществления privilege escalation
  RJF>> в будущем.
 
 Кстати, тот пример я привёл для одновременной демонстрации
 двух "противоправных" действий:
 * засорение диска в обход квоты
 * складирование suid root бинарей на будущее
 
  VW> Кстати говоря, вот тут понятие точек монтирования спасает
  VW> современные Unix-ы на 100%.
 
 Ясен пень.
 
  VW> Если какой-то обормот-админ дал юзеру права записи на
  VW> той же партиции, что у него /usr/sbin
 
 А также:
  /bin (login, su, mount, umount, ping)
  /sbin (unix_chkpwd)
  /usr/X11R6/bin (X)
  /usr/bin (at, chage, chfn, chsh, crontab, gpasswd, ...)
  /usr/lib (libfakeroot.so.X.X.X, pt_chown, ssh-keysign)
 :)
 
 В смысле, что обычно от остальных отделяют /home, /var и
 вообще все world-writable директории, а не директории с suid
 root бинарями.
 
 Hо это всё под корень рубит мечты иметь cross-mount
 hardlinks.
 
  VW> - баклан он, и никто более.
 
 Hо, тем не менее, это не повод оправдывать кривость
 hardlinks и безответственность их авторов.
 
 В придаточном предложении "баклан он, и никто более",
 ударение можно поставить и на "баклан", и на "он".  Я
 прокомментирую второй вариант. 
 
 Я абсолютно уверен, что баклан не только "он" (админ).
 Изобретатели hardlinks как раз и являются настоящими
 бакланами -- дристючим стадом бакланов.
 
 Основная проблема с hardlinks в том, что они не стыкуются
 с юниксоидной системой разделения прав.
 Ownership/permissions _файла_ на влияют на способность
 пользователей создавать его hardlinks.
 
 А по сути, пользователь, создавая hardlink чужого файла,
 как-бы заявляет намерение его использовать и сохранить от
 удаления (буде владелец вознамерится).
 
 Кстати, в подобном случае использование обычно ограничится
 чтением или исполнением. Почему бы тогда этот файл просто не
 скопировать? -- и можно было бы делать с ним что угодно...
 
 В результате, одна сторона файл использует, а другая
 расплачивается своей дисковой квотой.
 
 Получается, что для чтения и копирования файлов предусмотрен
 механизм защиты (read permission вместе с правами
 родительских каталогов), для исполнения и модификации тоже,
 а для блокирования удаления -- нет.
 
 Кстати, блокирование удаления -- очень частный аспект
 применения hardlinks. Семантически создание hardlink
 эквивалентно дополнительному классифицированию файла (что не
 есть полноценное изменение классификации, коим является mv).
 
 Скажем, возьмём /etc/shadow и доклассифицируем его как файл
 в очереди на печать, или в очереди отправляемых почтовых
 сообщений, или как web-страницу и т.д.
 
 Другое дело, что права доступа к очереди не позволят нам
 осуществить желаемую доклассификацию, да и сервис будет
 работать от непривилегированного пользователя, но суть
 проблемы становится очевидной:
   доклассификация, да и вообще реклассификация
   _должна быть ограничена_.
 
 Аналог из повседневной жизни: представь, что кто-нибудь
 "доклассифицирует" твой домашний номер как "секс по
 телефону".
 Или твой домашний адрес как "распродажа perfumes".
 
 P.S.
 Hаиболее разумной политикой, если не плодить лишние
 permissions или иные атрибуты, является запрет создавать
 hardlinks на чужие файлы любому индивиду, кроме
 суперпользователя.
 Такая политика используется в grsec.
 -- 
 Bye!
 Ramazan
 --- ifmail v.2.15dev5.3
  * Origin: UkrNet (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    Re: mc   Stas Baldin   05 Jun 2004 15:38:25   Re: mc   Leschinsky Oleg   06 Jun 2004 01:00:21   Re: mc   Victor Wagner   06 Jun 2004 18:05:18   Re: mc   Stas Baldin   07 Jun 2004 11:19:15   Re: mc   Stas Baldin   08 Jun 2004 13:15:57   Re: mc   Roman Belenov   07 Jun 2004 11:33:01   Re: mc   Victor Wagner   07 Jun 2004 12:12:55   Re: mc   Roman Belenov   08 Jun 2004 11:57:17   Re: mc   Victor Wagner   08 Jun 2004 12:33:02   Re: mc   Roman Belenov   08 Jun 2004 14:05:09   Re: mc   Victor Wagner   08 Jun 2004 14:14:41   Re: mc   Mikhail Gusarov   08 Jun 2004 16:58:31   Re: mc   Victor Wagner   08 Jun 2004 20:36:13   Re: mc   Ramazan Jah-Far   11 Jun 2004 01:12:04   Re: mc   Victor Wagner   11 Jun 2004 08:34:03   Re: mc   Ramazan Jah-Far   13 Jun 2004 05:11:07   Re: mc   Victor Wagner   15 Jun 2004 10:42:17   Re: symlinks vs. hardlinks   Ramazan Jah-Far   17 Jun 2004 00:45:33   Re: symlinks vs. hardlinks   Victor Wagner   17 Jun 2004 12:18:45   Re: symlinks vs. hardlinks   Ramazan Jah-Far   19 Jun 2004 04:16:30   Re: symlinks vs. hardlinks   Victor Wagner   19 Jun 2004 10:43:16   Re: symlinks vs. hardlinks   Ramazan Jah-Far   22 Jun 2004 00:01:11   Re: mc   Aleksey Barabanov   11 Jun 2004 10:36:11   Re: mc   Ramazan Jah-Far   13 Jun 2004 04:26:03   Re: mc   Aleksey Barabanov   13 Jun 2004 17:36:23   Re: mc   Evgeniy_Kozhuhovskiy   11 Jun 2004 16:48:24   Re: mc   Roman Belenov   08 Jun 2004 16:59:02   Re: mc   Aleksey Barabanov   08 Jun 2004 13:06:48   Re: mc   Valentin Nechayev   08 Jun 2004 13:14:05   Re: mc   Aleksey Barabanov   08 Jun 2004 13:46:41   Re: mc   Valentin Nechayev   08 Jun 2004 13:58:00   Re: mc   Aleksey Barabanov   08 Jun 2004 14:22:49   Re: mc   Alexander Drozdov   10 Jun 2004 02:49:30   Re: mc   Aleksey Barabanov   11 Jun 2004 10:36:10   Re: mc   Alexander Drozdov   12 Jun 2004 01:23:56   Re: mc   Aleksey Barabanov   12 Jun 2004 00:28:49   Moderatorial [ ] Предупреждение ( Re: mc)   Comoderator of RU.LINUX   15 Jun 2004 10:44:52   Re: mc   Serge Droutchin   16 Jun 2004 17:59:42   Re: mc   Victor Wagner   16 Jun 2004 18:53:04   Re: mc   Aleksey Barabanov   16 Jun 2004 20:19:51   Re: mc   Stas Baldin   08 Jun 2004 14:38:34   Re: mc   Aleksey Barabanov   08 Jun 2004 15:12:28   Re: mc   Stas Baldin   08 Jun 2004 16:08:50   Re: mc   Aleksey Barabanov   08 Jun 2004 16:56:53   Re: mc   Stas Baldin   08 Jun 2004 19:16:11   Re: mc   Artem Chuprina   08 Jun 2004 23:07:10   Re: mc   Aleksey Barabanov   09 Jun 2004 00:35:54   Re: mc   Stas Baldin   09 Jun 2004 09:07:39   Re: mc   Artem Chuprina   09 Jun 2004 18:30:58   Re: mc   Alexander Drozdov   10 Jun 2004 03:06:24   Re: mc   Alexander Drozdov   10 Jun 2004 03:01:24   Re: mc   Aleksey Barabanov   10 Jun 2004 19:16:30   Re: mc   Alexander Drozdov   12 Jun 2004 01:16:02   Re: mc   Kirill Frolov   09 Jun 2004 02:19:39   Re: mc   Victor Wagner   08 Jun 2004 15:17:07   Re: mc   Stas Baldin   08 Jun 2004 16:13:02   Re: mc   Victor Wagner   08 Jun 2004 16:41:48   Re: mc   Stas Baldin   08 Jun 2004 17:01:23   Re: mc   Valery Shishkov   09 Jun 2004 00:54:15   Re: mc   Kirill Frolov   09 Jun 2004 02:07:52   Re: mc   Alexander Drozdov   10 Jun 2004 02:45:04   Re: mc   Aleksey Barabanov   10 Jun 2004 19:13:50   Re: mc   Vasily Tchekalkin   09 Jun 2004 13:23:23   Re: mc   Aleksey Barabanov   10 Jun 2004 00:22:16   Re: mc   Vasily Tchekalkin   10 Jun 2004 10:23:23