"Инфу о пользователях все нормальные люди хранят в LDAP/NIS+, и такая "проблема" отсутствует."

ОК. Я не вхожу в категорию "нормальных людей"! Но ситуация при которой я смогу получить файлы /etc/shadow, /etc/group, /etc/passwd даже в случае сбоя файловой системы мне определенно нравится. Юзеры NTFS и пропадандируемых тобой LDAP/NIS+ такой возможности определенно лишены... И идет DSelect под расстрел "братков" за криворукость...

"# newfs -Nv /dev/rdsk/c0t2d0s4

# mount -F ufs -o largefiles,logging /dev/dsk/c0t2d0s4 /mnt

# ufsdump 0f - /dev/rdsk/c0t2d0s4 | (cd /mnt | ufsrestore xf - )"

Это вообще песня. Ни один "нормальный" админ не будет испольщовать devfs на боевых серверах! Сдается мне, что товарищ DSelect принадлежит к числу любимых господином Irsi "красноглазиков".

анонимус, ты конечно всё прикольно расписал, но есть одна проблема: чтобы сделать chmod надо быть владельцем файла/директории, просто входить в группу даже с правами записи недостаточно.

Единственное что нельзя сделать при восьмибитных правах на доступ - это разрешить создавать в директории новые файлы, но запретить удалять те, которые тебе не принадлежат. Но это решается установкой sticky-бит на каталог.

>Есть группа людей. У них одинаковые права на каталог - чтение и запись. Один человек хочет положить туда файл, но так, чтобы его видел только он и еще один человек из этой группы. Это можно сделать только с ACL? Или чего-куда?

Можно и без, но должна быть группа, куда входите только вы вдвоём

touch file

chgrp our_group file

chmod 660 file

В любом случае владелец каталога сможет файл изменить/удалить, поэтому им должен быть либо ты, либо друг, либо рут, либо пользователь без права входа в систему. . Чтобы файл не могли удалить входящие в группу с правом на запись, на каталоге должен стоять Sticky-бит.

>А еще вопрос - можно ли сделать, чтобы могли читать, менять существующий файл, но не могли добавлять свой или удалять файл?

jackill, права доступа описывают в первой главе любой книжки по юниксу. Но если так уж влом прочитать подскажу, что надо дать право только на чтение на директорию и на запись на нужный файл.

> root@Lord:/# chown serg.users /assa

Дебил вот здесь у тебя ошибка. Ты же тормоз предлагал на каталог smeta ставить владельцем smeta:smeta (смотри выше, где ты это говорил).
То есть владелец - группа:группа.

а в тесте ты ставишь user:group

Разницу чуешь, идиот ?

Для понимания этого и нужно абстрактное мышление.

А для решения твоей проблемы с потенциально "эксплойтируемой" дыркой в правах доступа нужно было ставить владельцем root:smeta.

> В любом случае владелец каталога сможет файл изменить/удалить, поэтому
> им должен быть либо ты, либо друг, либо рут, либо пользователь без
> права входа в систему. . Чтобы файл не могли удалить входящие в группу
> с правом на запись, на каталоге должен стоять Sticky-бит.

Спорим что ты не ROOT ? До его мозгов эта потенциальная дырка никак не доходит.

2 ROOT:

> Юзеры NTFS и пропадандируемых тобой LDAP/NIS+ такой возможности определенно лишены...

У NTFS, UFS, XFS таковые сбои бывают _крайне_ редко, и то -- если по серверу кувалдой грохнуть.

Что касается LDAP, то информация хранится в Berkeley db файле, и в чем сложность его резервного копирования -- совершенно не ясно.

> > # ufsdump 0f - /dev/rdsk/c0t1d0s4 | (cd /mnt | ufsrestore xf - )

> Это вообще песня. Ни один "нормальный" админ не будет испольщовать devfs на боевых серверах!

Дубинушка, то команды для Solaris написаны.

> У NTFS, UFS, XFS таковые сбои бывают _крайне_ редко, и то --
> если по серверу кувалдой грохнуть.

Dselect, ты конечно человек уважаемый, но вот пи****ть не надо

про "профессионалов"

2 ROOT:

> Моя зряплатка минимум в 5 раз выше.

Не волнуйся, те, кому жаль денег на нормального админа, быстро разоряются.

> Ты - аспирантик в Дубне.

Да, куда там той Дубне до "Рога и Копыта Ltd." (R) (TM)...

> Ты НИХУЯ даже не видел корпоративных компьютерных сетей.

Судя по той несусветной чуши, которую ты несешь ( a la юзверь X послает юзверю Y по почте файл на ТОТ ЖЕ САМЫЙ хост, вместо того, чтоб соответсвующие права поставить), сетей ты не видел вообще. Не только корпоративных -- но и вообще никаких.

Про синхронизацию всяких там passwd и shadow и говорить нечего.

> Если тебя интересует как что-то сделать

Та я и без засраных знаю, как расставить права на файлы. Без всяких костылей, о немеряной крутости которых ты тут распинаешься.

> А _ТРЕБОВАТЬ_ от сообщества ответы - это равносильно требованию подачек в электричках и метро.

Стоп. Кто-то тут ляпнул, что можно расставить права на файлы без ACL -- я за язык никого не тянул. Вот теперь пусть расскажет, КАК. Или скажет "не знаю". А иначе -- это просто 3.141592..здун, и разговаривать с ним нечего.

Мдя, народ точно Новелл не видел с его ACL, сейчас бы не было такого бы спора... А вот интересно. Хочу разрешить только права на каталог, где незя создавать, но можно модифицировать....и незя читать. :)

точнее наоборот, можно создавать, но нельзя модифицировать. :)

и незя удалять, а не читать...во. Простите, Новелла перед глазами нет, на память не помню все права, но их там больше чем rwx

Полюбуйтесь на примитив rwx Полномочия NetWare Права допуска Unix Read (чтение) Read (чтение) Write (запись) Write (запись) Erase (удаление) Write (запись) Create (создание) Write (запись) File Scan (просмотр файла) Read (чтение) Modify (модификация) Write (запись) Access Control (управление доступом) нет Supervisory (отслеживание) нет нет Execute (выполнение)

Полюбуйтесь на примитив rwx
	
Полномочия NetWare                     Права допуска       Unix
Read (чтение) 	                        Read (чтение)
Write (запись) 	                        Write (запись)
Erase (удаление) 	                Write (запись)
Create (создание) 	                Write (запись)
File Scan (просмотр файла) 	        Read (чтение)
Modify (модификация) 	                Write (запись)
Access Control (управление доступом)	нет
Supervisory (отслеживание) 	        нет
нет 	                                Execute (выполнение)

2 anonymous (23.02.2004 14:59:45):

> А вот интересно. Хочу разрешить только права на каталог, где незя создавать, но можно модифицировать....и незя читать. :)

http://www.linux.org.ru/gallery/bigimagMz.png

http://www.rsbac.org

И отказываться от ACL не то что глупо, а тупо....хоть какие то ACL чем вообще НИКАКИЕ

Dselect (*) (23.02.2004 16:06:57)

А это стандартные средства ЮНИКС? :) групы rwx? :) Это уже ACL

Эх, вошло бы это все в основную ветку ядра, или бы основные дистрибутивы поддерживали...

>То есть владелец - группа:группа. Я, конечно, не R00T, но ты юморист: владелец файла это всегда один человек.

И ещё может кто не знал, если на каталоги мете и мета_write поставить SGID, то создаваемые там файлы будут сразу относится к группам meta и meta_write соответственно. Так что не зря этот способ разграничения прав существует столько лет, просто он достаточно удобен и продуман.

ACL вводят не потому, что старым методом нельзя что-то сделать, а потому что у него есть определенные недостатки - на каждый чих нужна группа, а группы создает администратор, и ешё группы быстро размножаются. Но из недостатков прямо следуют достоинства - простота в использовании и проверке прав. Сделал ls -l и всё ясно.

Анонимус правильно сказал классический способ предполагает наличие продуманных статических правил совместного доступа к файлам, если правила меняются требуется вмешательство рута. Так что если вам сейчас нужно одно, а через час совсем другое, то ACL возможно будет удобней. Но тогда не удивляйтесь, почему черновик письма любовнице шефа прочитал бухгалтерский отдел.

таки почитайте доки по MAC

2 zim:

> Но тогда не удивляйтесь, почему черновик письма любовнице шефа прочитал бухгалтерский отдел.

Не помогут ни группы, ни [D]ACL. И не помешают :).

Для обеспечния конфиденциальности нужно использовать _другую_ модель безопасности.

P.S.

RTFM

простота?

2 zim:

> Но из недостатков прямо следуют достоинства - простота в использовании и проверке прав.

Задача: проверить, какими правами по отношению к директории /mnt/blah обладает пользователь pupkin.

> Сделал ls -l и всё ясно.

После того, как до просветления попялились в /etc/group.

А так -- getfacl /mnt/blah -- и все ясно.

нет, не совсем так как ты думаешь. до того я не имел дела с неподготовленными юзерами, которые слаще окошек ничего не видели. было много людей, но все они девелопили, настраивали свои машины и свои сервера сами - проблем не то чтобы не было - они не считались за проблемы. и помойки не было (те помойки что у каждого в ~user не считаются. они от головы). а когда стал иметь дело с теми кто считает что в килобайте 1000 байт так и понял что добрая воля не заменит ежевых рукавиц. и acl предпочтительнее, потому что позволяет делать веревку длиннее, но более чем необходимо. чтобы не удавились случайно :))

следует читать: но не более чем необходимо

Ну, да понадобится вторая команда: cat /etc/group | grep my_group, но зато сразу виден масштаб, вряд ли файлы в одной директории относятся к большому количеству групп.

Ты, кажется не понял, проблемы будут не в случае применения ACL самого по себе, а при отсутствии вменяемой политики в области безопасности.

То есть если я хочу дать Маше один файл, Саше другой, а Косте третий - мне три отдельные группы создавать? Я так опухну, как та коровка.

>что надо дать право только на чтение на директорию и на запись на нужный файл

А если "только на чтение" не хочется? Я говорил про один файл, а не про всю папку.

P.S. Я в курсе существующих прав. Вопрос был наводящий.

Тут выше все кричали, что ACL не нужен.

Думается, что очень даже нужен. И в частности как дополнительное улучшение политики безопасности.

> То есть если я хочу дать Маше один файл, Саше другой, а Косте третий -
> мне три отдельные группы создавать?

Именно.


> Я так опухну, как та коровка.

ниче, зато ROOT-у никак не помешает лишняя мозговая "деятельность" с группами. Глядишь и похудеет