ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Ramazan Jah-Far                      2:5020/400     19 Jun 2004  04:16:30
 To : Victor Wagner
 Subject : Re: symlinks vs. hardlinks
 -------------------------------------------------------------------------------- 
 

 Hi!
 In fido7.ru.linux, Victor Wagner wrote:
 
  RJF>> Hет. Hа мой взгляд, использование графа как семантической
  RJF>> модели ФС абсолютно бессмысленно. Я ещё могу допустить
  VW> Hа мой взгляд, разговор о "модели ФС" уже бессмысленен.
 
 Есть, во-первых, чисто практический смысл, а, кроме
 того, хороший повод поупражняться в жонглировании
 абстракциями, :) т.е. заняться тем, что в
 политкорректном варианте называется теоретизированием.
 
  VW> ФС сама по себе модель - модель отношений между разными кусочками
  VW> информации (не обязательно документами), хранящимися в компьютере.
 
 Hет. ФС просто-напросто предоставляет инструментарий для
 _управления_ кучкой файлов, принадлежащих пользователям,
 системе и прикладному ПО. _Управление_, согласно
 исторически сложившейся практике, проводится по принципам
 "divide et impera" и потому требует некоей абстрактной
 модели.
 
 Здесть есть динамика (управление) и статика (состояние ФС на
 некий момент). Если отделить первое от второго, получим
 бездыханный труп (ФС), которому BTW для _хранения_
 информации нафиг не нужны директории, права доступа и прочая
 "файловая система"-тичность. :)
 
  VW> Поэтому разговор идет о том, как бы приблизить эту модель к той модели,
  VW> которая используется для представления этих отношений в мозгу
  VW> пользователя. А вот там - заведомо граф.
 
 У меня -- не граф. Hе люблю лабиринты. :)
 
  RJF>> (1)  для любой ФС такого вида существует ориентированный
  RJF>>      ацикличный граф, вершины которого соответствуют "inodes",
  RJF>>      а рёбра -- "dentries" данной ФС.
  VW> Если он ориентированый, то у него дуги, а не ребра.
 
 Однако, да. :) Примем этот термин.
 
  RJF>>      // Т.е. _рёбра_ поименованы. Ребра с именем '/' нет. :)
  VW> Вот ацикличность - уже жесткое и ограничение, которое мешает жить.
  VW> Хотя можно его и пережить,  если уметь проходить по дугам в обратном
  VW> направлении.
  VW>
  VW> Второе ограничение - отсутствие некоей классификации дуг.
 
 А зачем? // Лучше на примере.
 
  RJF>> Логичнее всего считать, что недоступные из корня вершины
  RJF>> (inodes) нам не нужны, т.е. мы по-прежнему хотим
  RJF>> "односвязную" ФС.
  VW> Hе нужны?
 
 В том смысле, что вся недоступная из корня требуха
 считается удалённой и подлежит "сбору мусора".
 
 // Hа самом деле, журнал на ext3 чаще всего невидим, но
 // не "garbage collected", т.к. на его inode ссылается
 // superblock; так сказать, непоименованной дугой :)
 
 Таким образом, для большей корректности можем взять за
 отправную точку не '/', а superblock, и тогда в графе
 даже :) будет присутствовать дуга с именем '/'.
 
  VW> А зачем люди выдумали chroot и jail?
 
 А разве chroot делается не на подграф? т.е. не на некоторую
 "доступную" в текущем "графе" новую отправную точку?
 
  VW> Более того, стартовой вершиной, откуда пользователь начинает свой сеанс
  VW> работы с данной информационной структурой, никогда не является корень.
  VW> Это обычно либо ${HOME} , либо какой-нибудь "рабочий стол"
 
 Пользователь -- далеко не единственный пользователь ФС,
 есть ещё ОС и ПО.
 
  RJF>> В самом деле, тебе же не интересно, через какие промежуточные
  RJF>> хосты к тебе приходит файл из Internet?
  VW> Иногда - интересно. В тех ситуациях, когда оно тормозит и пакеты теряет.
  VW> Тогда я хочу знать какого админа из промежуточных пинать.
 
 Для этого существует спец. API. А _голый_ send/recv тебе не
 скажет ни про промежуточный хост, ни про его админа.
 
  RJF>> Выходит, в действительности выполняемые ФС функции намного
  RJF>> ближе к каталогизации (классификации). Сравни с библиотекой. ;)
  RJF>> И "ФС-путь" семантически намного ближе к "классу", нежели к
  RJF>> "маршруту".
  VW> Совершенно верно. Hо тут есть такая маленькая тонкость - классифицируем
  VW> мы объекты не вообще а по отношению к какой-нибудь задаче.
 
 Скажем так, ФС предоставляет инструмент, а задачи определяет
 ОС, ПО и пользователи, в рамках своих полномочий.
 
 Для ОС основная задача, грубо говоря, -- полийейский надзор
 за пользователями и ПО (и их файлами).
 
 Управлением ПО обычно занимается package manager (PM), но,
 если ФС предоставит соответствующий инструментарий, PM
 значительно упростится, т.к. отпадёт нужда в "побочных" :)
 БД.
 
 Пользователь в своём "домене полномочий" волен
 классифицировать файлы по съедобности, стеклянности и вообще
 как угодно соответственно своим задачам или целям,
 поставленным перед ним его работодателем.
 
  VW> Если мы ухитримся представить задачи в виде объектов того же множества,
  VW> то классификации образуют как раз-таки ациклический граф.
 
 Это я не понял. Смотря как вести дуги.
 Многие объекты будут участвовать в разных задачах, со всеми
 вытекающими, типа непреодолимого желания наложить
 классификации друг на друга...
 
  VW> Если все классификации одноуровневы, а множества задач и
  VW> классифицируемых объектов не пересекаются, то граф будет двудольным.
 
 Вот это понятно. Hо только одноуровневая классификация --
 это нечто навроде "вино/брэнди/виски". :)
 
  RJF>> Теперь про само намерение delete. Оно возникает довольно
  RJF>> часто. К примеру, delete /usr/sbin/sendmail при выполнении
  RJF>> security update.
  VW> Hу вот как раз ни в коем случае в этой ситуации нельзя delete.
  VW> Мало ли каким процессам в данный момент этот бинарник нужен.
 
 Дело в том, что я здесь имею в виду "FS-delete", а не
 "VFS-delete". Счётчик ссылок на файл изнутри ФС -- не одно и
 то же, что счётчик ссылок на файл в драйвере ФС.
 
 Т.е. delete, _конечно же_, откладывается до закрытия всех
 дескрипторов файла ОСью.
 
 // unlink становится delete-ом, когда обнуляется счётчик
 // ссылок на файл изнутри ФС.
 
  RJF>> А теперь представим, что юзеров прищучили жёсткими квотами,
  RJF>> места на винте мало, а некий /home/someuser содержит
  RJF>> полную антологию за 15 лет sendmail-ов, apache-й, ssh-ей,
  RJF>> ssl-ей, ядер и прочей регулярно обновлявшейся требухи, в виде
  RJF>> hardlinks. ;)
  VW> Чушь ты какую-то несешь.
 
 Сразу видно, что ты не прочитал про баг #какой-то-там.
 Это security stuff.
 
 Смысл в том, что злонамеренный пользователь откладывает (ln)
 suid-ные бинари впрок для осуществления privilege escalation
 в будущем.
 
 После того, как обнаруживается очередной exploitable баг в
 том же sendmail, пользователь ищет exploit, но чаще всего
 администратор успевает обновить sendmail раньше.
 
 Однако у пользователя на этот случай есть заблаговременно
 припасённый _suid root_ sendmail, а всё благодаря hardlinks.
 // и использованию пакетным менеджером unlink вместо
 // shred/delete/(chmod gu-s && unlink)
 
 Так что намерение delete совершенно правомерно, в данном
 примере, -- по отношению к дырявым suid root бинарям.
 -- 
 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