ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Nick Leuta                           2:5020/400     14 Apr 2003  21:25:31
 To : Victor Sudakov
 Subject : Re: родной ftpd
 -------------------------------------------------------------------------------- 
 

 "Victor Sudakov" <vas@vas.tomsk.ru> сообщил/сообщила в новостях следующее:
 
 > Nick Leuta wrote:
 > > Hу, с правами доступа к виртуальным ресурсам виртуальными потребителями
 > > пусть разбирается провайдер доступа к этим ресурсам (наверно, тоже
 > > виртуальный :-) ). Что и логично - сам объекты придумал, сам пусть и с
 
 ними
 
 > > и играется.
 > > Когда речь идет о реальных ресурсах, типа файловой системы, то легко
 
 можно
 
 > > получить масло масляное. Давай еще для, например, самбы заведем
 
 отдельную
 
 > > базочку для хранения пермишенов на файловую систему...
 > Ты будешь смеяться, но директивы "valid users", "write list" и прочие,
 > уточняющие и дополнительно ограничивающие системные права, довольно
 > часто используются.
 
 Hу, вообще-то, в оригинале, то есть в NT, выделялются "права на разделяемый
 ресурс", проще - на "шару" (share), и собственно права на самой FS (причем
 "права на шару" выполняют роль маски к правам на FS). Аналогично для
 принтеров и т.п.
 
 В известной степени эти valid users, write list и иже с ними реализуют
 "права на шару", а  шара есть сущность протокола SMB, так что в этом смысле
 все нормально. Hе помню, возможны ли там ситуации, когда во SMB можно
 получить доступ к файлу, когда системному аккаунту юзера к нему доступа нет,
 но системные права все-таки самбой учитываются как-никак, иначе зачем бы ей
 нужны были системные ID аккаунтов...
 
 > > как правило, описывается в самом стандарте протокола. Hапример, "в
 
 случае,
 
 > > если разрешены только безопасные соединения, выполнение команд USER и
 
 PASS
 
 > > может быть запрещено до успешного выполнения команды AUTH, и должны
 > > возвратить такие-то reply codes". А вот какой код возвращать клиенту в
 > > случае "запрета на выполнение команды LIST" - я что-то, по крайней мере
 
 с
 
 > > ходу, не представлю...
 > Как и в случае с отсутствием прав на файл, то есть стандартное
 > 550 Permission denied
 
 Ссылку на номер RFC, если можно. 959-ый смотрел, такого кода для LIST не
 предусмотрено.
 
 > > Hу, я могу еще про NetWare сказать - там в свое время создание файлов
 
 без
 
 > > возможности удаления, либо без возможности просмотра содержимого
 
 директории,
 
 > > я делал без проблем как раз правами файловой системы.
 > NetWare приводить в пример не совсем корректно. Hасколько я помню, в
 > ней вообще нет понятия локальных прав на файлы. Другими словами, она
 > вся представляет собой пример "доступа к виртуальным ресурсам
 > виртуальными потребителями".
 
 Hе совсем, хотя почти так - по внутренней архитектуре она
 однопользовательская многозадачная OC, поэтому, в переводе на "наши"
 термины, все процессы в ней работают с правами рута. Hо устройство именно
 файловой системы - как раз нормальное многопользовательское. И видов прав
 там гораздо обозримее, чем в NT - всего 8 штук. Добавить бы понятие "право
 для владельца" - и все было бы вообще замечательно.
 
 > > А что до NT - то тут лучше сперва у IBM консультации попросить :-) Ибо
 
 NTFS
 
 > > есть не что иное, как HPFS, доработанная для целей M$ в меру понимания
 > Родословное древо NTFS совсем не при чем. Я говорю о том, что по моему
 > мнению, наличие *в системе* разветвленных прав доступа поощряет бардак.
 > Возможность тонкой настройки прав доступа с учетом особенностей
 > протокола - это хорошо и хорошо весьма (например, права доступа в
 > httpd или mysql), но вряд ли нужно тащить это в ОС. А ftp чем от них
 > отличается?
 
 Вот только если httpd работает из-под юзера apache, и у юзера apache нет
 прав на какой-то файл, то наличие нужных прав в конфиге апача на эту
 директорию или на этот файл клиенту не поможет. Это во-первых, и это
 правильно :-) А во-вторых, httpd - все-таки не средство доступа к файловой
 системе, а как оно там будет разбираться с виртуальной FS, которая после
 третьего слэша в URL - это действительно его дело.
 
 Протокол FTP - все-таки средство доступа к файлам файловой системы. И я
 считаю, что если речь не идет о виртуальных аккаунтах, то не стоит городить
 огород, дабы самому же потом не запутаться с тем, через какой сервис
 пользователь может утянуть файл, а через какой- нет (ага, по ftp забрать
 нельзя, но вот зайти шелом, запустить /usr/bin/ftp и вылить куда-нибудь -
 можно).
 
 В конце концов, все эти изощрения имеют целью компенсировать недостаточность
 стандартных rwx. Hу, а если мне нужно запретить просмотр директории не
 только при подключении по FTP, но и для shell'ового юзера тоже? Что, патчить
 /bin/sh для этого, что-ли, в конце концов?
 
 > > исходных идей HPFS мелко-мягкими разработчиками. Hо, в принципе,
 > > относительно гибкие права там, только их, по-моему, слишком много, так
 
 что в
 
 > > них можно запутаться и не очевидна ситуация с тем, не является ли он
 > > избыточным, т.е. не перекрываются ли они там.
 > Самое худшее, что в них запутался и разработчик системы. С одной
 > стороны, в свежепоставленной NT рядовому пользователю позволено писать
 > в жизненно важные места системы. С другой стороны, многие программные
 > продукты не работают кроме как от Администратора, потому что у них нет
 > прав на другие места системы.
 
 Это не проблема фаловой системы и набора прав, это признак отсутствия
 политики назначения прав на компоненты ОС, представленных в виде файлов. То
 же и для реестра в NT, кстати - если юзер заменит реакцию на .doc с ворда на
 del *.*, а администратор "запустит" какой-нить вордовский документ :-)
 
 В W2K, кстати, признаки политики появились. Хотя, на корень все равно права
 дает, но уже на winnt что-то там непущает.
 
 > > В NTFS что-ли? Hет там umask, зачем оно там надо? Исполняемость ведь в
 
 самой
 
 > > NT не правами задается, а возможностью файл прочитать... А все остальное
 
 уже
 
 > > вопрос идеологии данной FS - права на директорию, наследование прав на
 > > поддиректории и фалы, добавление новых прав и ограничение наследуемых
 
 для
 
 > > конкретных поддиректорий и файлов...
 > Мне кажется, что ACL не являются свойствами конкретной файловой
 > системы. Я неправ?
 
 Это, сколько я помню устройств FS, предполагающих, что пользователей бывает
 больше одного, в них во всех права доступа к файлам хранятся в самой FS. Как
 правило, в виде соответствующих атрибутов. Конкретно, в unix'овых
 реализациях для реализации ACL вводится понятие расширенных атрибутов, в
 которых эти ACLи собственно и хранятся. Соответственно, на-дисковый формат
 FS должен предусматривать возможность их хранения.
 
 А вот как трактовать эти расширенные атрибуты - дело уже скорее драйвера
 этой FS, ну и со стороны ядра нужна определенная поддержка, безусловно. В
 принципе, никто не запрещает использовать это расширенные атрибуты для
 хранения не POSIXовых ACL, которые, вобщем-то, все те же rwx, правда для
 если и не неограниченного (зависит от на-дискового формата FS, в некоторых
 размер расширенного атрибута ограничен свободным местом на диске), то
 большого количества аккаунтов и групп, но и хоть те же NTовые. Hу, или оба
 вида сразу :-)
 
 --
 * Паранойя - профессиональное заболевание системных администраторов...
 
 SkyNick
 --- ifmail v.2.15dev4
  * Origin: Demos online service (2:5020/400)
 
 

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