> Пример: как разрешить узеру Васе читать/писать в мой файл, узеру Пете -- читать/исполнять, узеру Вове -- ничего не разрешать, всем остальным -- только читать, ЕСЛИ я не root?

Ты не root, тебя зовут проще - дрочун. От слова "дрочить".

2anonymous (*) (20.02.2004 14:05:55):
"А как запретить тем кто находится в группе smeta удалять файлики (кстати недоступные ему на запись) ?"
Сам-то хоть понял, какую чушь написал?
Хотя... :-) Я понял. Ты, небось, из-под Самбы умеешь удалять файлышки, прав на rw на которые у тебя нет? Ну так, надо криворукому мудачку, который smb.conf рисовал, яички оторвать!

Dselect (*) (20.02.2004 14:14:41):
"1) Как пользователь из группы smeta_write может предоставить права на запись ( в файл, которым он владеет) _одному_ пользователю из группы smeta?"
Да как угодно. Может, например, переслать файл по локальной почте коллеге "на редактирование", а потом положить назад.
И _НЕ НАДО_ трындеть, что "это не наш путь". Как раз-таки наш. Ты просто никогда не админил сети в организациях, вот и трындишь... Печальная практика показывает, что стоит всем юзерам разрешить писать хотя бы в один общий каталог, как мигом все файлы оказываются именно в этом каталоге. И найти что-то нужное становится либо невозможно, либо очень сложно. Для того и вводится ограничение прав доступа, чтобы такую ситуацию не допустить.

"2) Как пользователь из группы smeta_write может запретить всякий доступ ( к файлу, которым он владеет ) одному (или нескольким) пользователям из группы smeta?"
Запретить доступ легче легкого: перенести файл в свой "домашний" каталог. Реально же, что-то у нас таких ситуаций не возникает: файлы внутри отдела являются общими для отдела. Единственное но: есть файлы, которые предназначены "для глаз" только начальников отдела. Ну и что? Просто начальники отделов имеют соответствующие права на доступ к каталогу "administration".
В любом случае, вопрос об ограничении доступа сотрундика к информации решается на уровне начальников отделов или выше. В случае необходимости, просто создаются отдельные каталоги и отдельные группы пользователей, имеющие права на расширенный доступ.
Кстати, такая система реализована прямо внутри общего проекта для всех подразделений компании. Проект (с раздачей всех прав и созданием всех симлинков)создается 1-й командой: "makeproject {имя_проекта}" :-)
Фактически, реализована система электронного документооборота (правда, нет механизма "электронной подписи", но ничего страшного).

"Когда все Linux'-овые FS будут поддерживать ACL, красноглазые будут орать о немеряной их крутости. Та же история, что во времена 2.2 была с журналированием..."
Вот когда ACL реализуют в полном объеме, тогда и будет разговор. В настоящий момент, реализация ACL в Linux оставляет желать очень много лучшего (с точки зрения безопасности данных, прежде всего).

"Расскажи-ка мне, касатик, а как запретить юзверю сделать chmod 666 какой-то-его-файл? ( Без какого-нибудь MAC framework вроде SELinux или RSBAC )"
Странненько. А зачем ему это запрещать? Ограничение на доступ "чужих" стоит в каталоге более верхнего уровня, так что ограничивать доступ еще и на всех нижестоящих уровнях - как минимум бесполезно.

"Если ROOT будет иногда думать, то может, он и сообразит, что хранить информацию о правах доступа нужно в метаданных ФС, а не в /etc/group."
Если DSelect когда-нибудь (в будущем) будет администрировать компьютерную сеть в организации, он сообразит: использовать текстовые файлы для хранения информации о пользователях очень сильно облегчит жизнь в случае сбоя системы или при необходимости переустановки (переноса на другую машину) ОС и данных.

> а как запретить юзверю сделать chmod 666 какой-то-его-файл?

mount -o noexec ;)

А вообще, я как посмотрю, ты жуткий извращенец. Упорно требуешь права
заниматься сексом стоя в гамаке в водолазном костюме. Тебя пытаются
отговорить, а ты всё равно кричишь "А я Хочу!" ;) Ну что же... Юникс
очень гибкая система ;)

> mount -o noexec ;)
Ай, извиняюсь, мне почему-то показалось 777.

> Сметно-договорной отдел имеет каталог "smeta-dogovor". Заходить в него
> могут только члены группы "smeta" (права на каталог r-xr-xr-x,
> группа-владелец "smeta").
> На файлы/каталоги внутри него стоят права rwXrwXr-X, группа-владелец у
> них - "smeta_write". Всё. Задача решена. Те пользователи, которым
> разрешено только чтение - состоят в группе "smeta", а тем, кому
> разрешено чтение-запись состоят в группах "smeta" и "smeta_write".
> Что тут трудного-то?

Поставим вопрос по другому - а кто сможет создать в этой директории файлик-то ? да хоть ты в одной группе, хоть в обоих, пока ты не ROOT - шиш.

Поставишь rwxr-xr-x на каталог - smeta сможет удалять файлики не доступные ему на запись. А поставить он и сам поставит (владелец как никак) - rwxrwxrwx. И поудаляет все файлики которые ему только на чтение даны.

Теперь дошло ? и самба тут ни причем

про noexec ( старо, как мир )

2 anonymous (*) (20.02.2004 15:11:09):

> > mount -o noexec ;)

> Ай, извиняюсь, мне почему-то показалось 777

Даже если 777

# mount -t tmpfs none /mnt/test -o size=10m,mode=1777,noexec,nosuid,nodev

$ cp /bin/bash /mnt/test

$ /mnt/test/bash -c "echo test"

bash: /mnt/test/bash: Permission denied

$ /lib/ld-linux.so.2 /mnt/test/bash -c "echo test"

test

# umount /mnt/test

> Если DSelect когда-нибудь (в будущем) будет администрировать
> компьютерную сеть в организации, он сообразит: использовать текстовые
> файлы для хранения информации о пользователях очень сильно облегчит
> жизнь в случае сбоя системы или при необходимости переустановки
> (переноса на другую машину) ОС и данных.

ROOT в жизни не видел новеля %)))
мне пришлось 3 раза переустанавливать новель на одном и том же диске (смена железа, винты те же самые) и ни разу не пришлось заново прописывать все права. Только пользователей соответствующих завести - и вуаля - все права как были так и остались. И текстовой файлик где были бы прописаны были права пользователей мне как-то совсем не пригодился.

Будь полноценный ACL в линуксе - можно было бы тоже самое и здесь провести - но увы!

RTFM, блин!

2 ROOT:

> Запретить доступ легче легкого: перенести файл в свой "домашний" каталог.

1) _ОДНОМУ_ пользователю, а не всей группе.

2) Так получаются файлопомойки.

> Да как угодно. Может, например, переслать файл по локальной почте коллеге "на редактирование", а потом положить назад.

А еще можно на бумажечке распечатать и отправить по обычной почте.

Автоматизация документооборота, твою дивизию...

> И _НЕ НАДО_ трындеть, что "это не наш путь". Как раз-таки наш.

Хвала Великим Богам, что _только_ ваш...

> > а как запретить юзверю сделать chmod 666 какой-то-его-файл?

> Странненько. А зачем ему это запрещать?

А как же

> Что касается "юзер пусть сам права раздает" - это ты будешь начальству песенки петь.

> Ограничение на доступ "чужих" стоит в каталоге более верхнего уровня, так что ограничивать доступ еще и на всех нижестоящих уровнях - как минимум бесполезно

Чушь. Никакой DAC не помешает сделать

cp /some/dir/x_file ~/ ; chmod 777 ~/ ; chmod 666 ~/x_file

> Вот когда ACL реализуют в полном объеме, тогда и будет разговор. В настоящий момент, реализация ACL в Linux оставляет желать очень много лучшего (с точки зрения безопасности данных, прежде всего).

ACL здесь НЕ ПРИ ЧЕМ. Читать ЛаПадулу до полного просветления.

Начать можно здесь: http://www.acsac.org/secshelf/book001/book001.html

А никто в каталоге "smeta-вщпщмщк" файлы создавать и не должен. В нем находятся определенные каталоги (Акты, Договора, Сметы и т. д.), вот на них-то и стоит группа-владелец "smeta_write". И внутри них могут файлы создаваться/редактироваться. Права наследуются соответствующими опциями в smb.conf типа "create mask" и "directory mask". По уму, и в эти каталоги писать юзерам не надо: в них находятся симлинки на соответствующие разделы внутри проектов.

То бишь, юзер заходит в Smeta-dogovor->Акты->{имя_проекта} (реально попадая куда-нибудь в \\fileserver\projects\{имя_проекта}\Акты) и писать может только уже вовнутрь проекта.
Симлинки с {имя_проекта} создаются автоматически при создании проекта. Права на каталоги раздаются тоже автоматически.

"Поставишь rwxr-xr-x на каталог - smeta сможет удалять файлики не доступные ему на запись."
Еще раз повторяю: только что проверял, юзер, состоящий в группе (группа имеет r-X) у меня почему-то удалить файл/каталог не может. Наверное, у меня кривые руки? Или это 9-я Слакварь глючит так?

любителю Новеля.

2 anonymous (*) (20.02.2004 16:20:11):

> Будь полноценный ACL в линуксе - можно было бы тоже самое и здесь провести - но увы!

Вам сюда: http://www.rsbac.org/models.htm#acl

2 anonymous (*) (20.02.2004 9:58:27)

>Всё что вы перечислили легко делается без ACL. А если не легко то ACL >ничего всё равно не упрощает.

Если это относилось к моей мессаге от (20.02.2004 5:52:45) - то пожалуйста покажите как. А то что то мне подсказывает что без ACL это невозможно.

> никто в каталоге "smeta-вщпщмщк" файлы создавать и не должен. В нем
> находятся определенные каталоги (Акты, Договора, Сметы и т. д.), вот
> на них-то и стоит группа-владелец "smeta_write". И внутри них могут
> файлы создаваться/редактироваться.

Перечитай свой оригинальный пост по этому поводу. Ты имел в виду что файлы хранятся сразу в этой директории , а не в каталогах ниже по иеррахии. Ну да ладно.
В предложенном тобой случае - smeta получает право изменить права доступа к каталогу и удалить уже не файлы, а целиком каталоги с файлами.


> Права наследуются соответствующими опциями в smb.conf типа "create
> mask" и "directory mask". По уму, и в эти каталоги писать юзерам не
> надо: в них находятся симлинки на соответствующие разделы внутри
> проектов

Мы обсуждаем права доступа локальных пользователей к файлам, а не какие права получаются у вин-пользователя через самбу.


> Еще раз повторяю: только что проверял, юзер, состоящий в группе
> (группа имеет r-X) у меня почему-то удалить файл/каталог не может.

Через самбу что-ли? ты в шеле сначала попробуй. пользователь элементарно может удалить любые файлы/каталоги (независимо от их прав доступа и владельцев) в директории где он имеет право на запись. Если же он владелец этого каталога то сменить права доступа к каталогу - раз плюнуть.

держи пример - скопирую в домашнюю директорию /home/test файлик xxx от рута с правами 700 root:root. таким образом имеем файл доступный только руту - /home/test/xxx. Угадай с двух раз сможет ли test удалить этот файлик, который он даже прочитать не может ?

> Наверное, у меня кривые руки? Или это 9-я Слакварь глючит так?

Кривые мозги у тебя. Каталог - это файл (по идеологии). И получаем то что получаем - права на каталог даются по той же схеме что и на файл, хотя суть этих прав совершенно разная. Возможность писать в каталог означает возможность создания или удаления в нем файлов.

Не завидую я твоим пользователям.

> В предложенном тобой случае - smeta получает право изменить права доступа к каталогу и удалить уже не файлы, а целиком каталоги с файлами.

Разрешите я нарисую для тормозов схему, а то R00T не обладает нужными
педагогическими способностями. Ну разве что с ноги в морду лица двинуть ;)

smeta_dogovor - сюда может войти только группа smeta
| |
boss smeta_write

В smeta_write может писать только группа smeta_write, остальные могут
только читать, причем остальные - это юзеры из группы smeta.
Каталог smeta_write защищен от стирания членами группы smeta_write.
Так ясно?

>Когда все Linux'-овые FS будут поддерживать ACL, красноглазые будут орать о немеряной их крутости. Та же история, что во времена 2.2 была с журналированием...

Так ведь уже того, все поддерживают. То, что этого нет в 2.4 с kernel.org не проблема :-)

Для тех, кто еще не понял, в чем суксь ACL'ов. Обычными средствами манипулирования группами админ создает статическую схему безопасности,
которую при желании можно проверить и доказать, какой бы сложности и объемности она ни была. ACL'ы - это постоянно меняющаяся, почти
неконтроллируемая схема. Вы никогда не можете сказать, сколько там входов и выходов, и как они взаимосвязаны.

>На файлы/каталоги внутри него стоят права rwXrwXr-X, группа-владелец у них - "smeta_write". Всё. Задача решена. Те пользователи, которым разрешено только чтение - состоят в группе "smeta", а тем, кому разрешено чтение-запись состоят в группах "smeta" и "smeta_write". Что тут трудного-то?

И что, на каждый создаваемый внутри этого каталог снова права править? Ой, я не могуууу :-)

RTFM

2 anonymous (*) (20.02.2004 17:31:38):

> Обычными средствами манипулирования группами админ создает статическую схему безопасности

1) Ничего подобного. Владелец файла может произвольно менять права -- независимо от наличия/отсутствия ACL( chmod 666 x_file ). Другое дело, что ACL позволяют предоставить минимально необходимые (и достаточные) права ( setfacl -m u:vova:rw- x_file; setfacl -m u:vasya:r-x x_file; setfacl -m u:vanya:r-- x_file; setfacl o::--- x_file )

2) The notion of superuser is the root of all evil.

> которую при желании можно проверить и доказать, какой бы сложности и объемности она ни была.

Учить матчасть, живо! Ссылку на работы ЛаПадулы я уже давал.

> ACL'ы - это постоянно меняющаяся, почти неконтроллируемая схема. Вы никогда не можете сказать, сколько там входов и выходов, и как они взаимосвязаны.

Не приписывать глюки DAC как такового -- которые НЕ ЗАВИСЯТ от его конкретной реализации -- реализации DAC с помощью ACL.

Хочу задать вопрос.

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

Это можно сделать только с ACL? Или чего-куда?

P.S. Фишка в том, что про ACL я мало что знаю и думаю, стоит ли мне покопать слегка в этом направлении, чтобы тему разрюхать.

2 jackill:

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

Если имеется в виду open, то

$ setfacl -m g::--- secret.txt

$ setfacl -m o::--- secret.txt

$ setfacl -m u:vasya:r-- secret.txt

НО: группа может делать stat, может удалить этот файл.

>Обычными средствами манипулирования группами админ создает статическую схему безопасности,

Все с точностью до наоборот. Вместо того, чтобы иметь _одно_ место выставления прав, местная звезда рут предлагает еще активно прописывать права в smb.conf. Это как раз не создает никакой схемы безопасности. Не говоря уж о локальном доступе, доступе по ftp и т.д.

рут и компания как всегда в своем репертуаре. не будьте тупыми уродами хоть раз. acl рулит если нужно чтобы _разделение_прав_ реально работало, а не было для галочки, для создание файлопомойки или для приковывания админа к консоли и телефону. пару лет назад в похожем споре на лоре я учавствовал на стороне 3+3 прав, но с тех пор успел порулить сетью и понять что 3+3 не подходит для сколь-нибудь приличного файл-сервера. а изголяться с линками - вообще маразм :-/

>Так можно договориться до того, что права доступа вообще не нужны

Конечно. ITS рулит. ;-)

>А чего тут трудного? К примеру:
>Сметно-договорной отдел имеет каталог "smeta-dogovor". Заходить в него >могут только члены группы "smeta" (права на каталог r-xr-xr-x, >группа-владелец "smeta").

Заходить в него могут не только члены группы "smeta" ;)

HellAngel (*) (20.02.2004 19:20:42):
2.5 года назад система была реализована. С "нуля". И с тех пор никаких принципиальных изменений не произошло. Ну разве что подразделений в организации прибавилось...
Итак, проект состоит из каталогов подразделений: сметно-договорного, иллюминационного, конструкторского, снабжения, директората, финансового и т. д.
Симлинками всё заводится на каталоги соответствующих отделов. К примеру:
конструктор заходит (в винде) в каталог p:\{имя_проекта}, а реально это тождественно \\fileserver\projects\{имя_проекта}\Технический_проект (то есть, на сервере, /pub/projects/{имя_проекта}/Технический_проект),
снабженец заходит (в винде) в каталог p:\{имя_проекта}, а реально это тождественно \\fileserver\projects\{имя_проекта}\supply (то есть, на сервере, /pub/projects/{имя_проекта}/supply)
ну и т. д., в то же духе.
А директоры заходят в p:\{имя_проекта} и попадают в \\fileserver\projects\{имя_проекта} (то есть, /pub/projects/{имя_проекта})
Реально, без симлинков, такое сделать нереально.

Опять же, резервное копирование, восстановление, переезд и прочее такой системы минимально прост: переписать на новый сервер файлы /etc/shadow, /etc/passwd, /etc/group и содержимое /pub/projects и /pub/homes, ну и симлинки в автоматическом режиме создать одним-единственным скриптом. Всё. И это - не пустые слова. На мартовские праздники в 2003-м году это всё было реализовано. Юзеры ушли 7 марта домой после рабочего дня, а 11 пришли на работу и уже работали с новым сервером. И даже не заметили никаких сбоев/различий/непонятностей. :-)

ну сорри, имелось в виду r-Xr-X---. Опечатался. Все поняли. Только ты не понял. :-)

> acl рулит если нужно чтобы _разделение_прав_ реально работало, а не было для галочки, для создание файлопомойки

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

> Один человек хочет положить туда файл, но так, чтобы его видел только он и еще один человек из этой группы.

Все проблемы от непонимания ;) В твоем раскладе самое оно - использовать
шифрование открытым ключом. Это если людей именно двое. Ты и еще один.

дело хозяйское, но это только твое ИМХО. рут написал что система была организована с нуля. а обычно в реальном мире такого обычно не случается. груз старых решений и ошибок проектирования (не важно чьих, собственных или предшественников) здорово осложняет жизнь. я с ходу могу вспомнить только одну ситуёвину, когда юниксовые права не позволили мне осуществить задуманное. впрочем, виндовые acl тоже не помогли, но в этом была не их ущербность, а ошибки в реализации afp-протокола в оффопике (или ограничения самого протокола - с этим я не стал разбираться, не до того было). мне нужно было создать файловый ресурс, в который один человек мог бы добавлять файлы, а другие _только_ читать и удалять. т.е. - оператор сканера кидает свежий скан в папку, а другие пользователи должны забирать файло. windows acl давал мне такую возможность, но только по smb-протоколу :( из двух зол мне пришлось выбрать меньшее - короткая инструкция и команда в кроне, чистящая содержимое каждую субботу чтобы ни у кого не возникло даже мысли использовать директорию в качестве помойки :)) с тех пор к юниксовым правам доступа отношение более чем скептическое. предложения "поставить клиента smb-сети на мак" отметаются как дорогие плохо работающие. нетварь отсекается скальпелем :)) acl + xfs + quota для одной задачи небольшой перебор, да и время упущено - в другой конторе я теперь

>пару лет назад в похожем споре на лоре я учавствовал на стороне 3+3 прав, но с тех пор успел порулить сетью....

Очень характерное для лора высказывание. В споре участвовал, но с тех пор успел порулить сетью (учитывая, к тому же, что всего "пару лет")

"А как сопел, как сопел" (с) Древний анекдот.

Читать и удалять, т.е. менять они файл не могли (т.к. прав на запись не было)?

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

> smeta_dogovor - сюда может войти только группа smeta
> | |
> boss smeta_write

> В smeta_write может писать только группа smeta_write, остальные могут
> только читать, причем остальные - это юзеры из группы smeta.
> Каталог smeta_write защищен от стирания членами группы smeta_write.
> Так ясно?

ROOT главное утерся, а этот выпендривается. Ну ладно, для тормозов - еще раз.

smeta_dogovor принадлежит каталогу smeta, на который права (по последним ROOTовксим понятиям) r-xr-x---, владелец smeta, группа smeta.
Так вот, кто мешает этому самому smeta выставить права на _свой_ каталог smeta права rwxrwx ? Правильно - никто, это его каталог и он сам решает какие права выставлять. А теперь фокус - раз он имеет каталог с правами rwx, кто мешает ему удалять файлы/каталоги лежащие в нем и/или создавать новые ? Тоже правильно - никто.

Вывод - smeta может в этом каталоге делать все что хочет, и ны ты, тормоз, ни ROOT с этим ничего сделать не можете.

ROOT-а спасает то что этот каталог расшаривается через самбу и является "корневым", поэтому сменить права на него пользователь smeta через винду не может, хотя через консоль/терминал - пожалуйста.
Если бы ROOT допустил _еще_ одну ошибку и расшарил бы не сам каталог smeta а его родителя (то есть в виндах было бы X:/bla-bla-bla/smeta/smeta_dogovor) он на вышеуказанные грабли бы давно наступил и выгнали бы его с позором, несмотря на 9-ю слаку.

2anonymous (*) (21.02.2004 7:53:31): Создал файл ./assa (rw-r--r--, serg@users). Зашел под пользователем lord@users. Делаю:

lord@Lord:/inbox$ chmod g+w ./assa
chmod: изменение прав доступа для `./assa': Operation not permitted
lord@Lord:/inbox$ rm -f ./assa
rm: невозможно удалить `./assa': Permission denied

Создал каталог ./bssa (rwxr-xr-x, serg@users). Делаю:

lord@Lord:/inbox$ chmod g+w ./bssa
chmod: изменение прав доступа для `./bssa': Operation not permitted
lord@Lord:/inbox$ rm -f ./bssa
rm: невозможно удалить `./bssa': Permission denied
Система - Slackware-9.1 Linux 2.4.24.
Об[ясни мне пожалуйста, что же я делаю "не так"? Заодно и расскажи достопочтенноуважаемой публике, где же ты травы-то такой набрал посреди зимы?

Я конечно понял что ты дебил, но чтобы настолько %)))

> 2anonymous (*) (21.02.2004 7:53:31): Создал файл ./assa (rw-r--r--,
> serg@users). Зашел под пользователем lord@users. Делаю:

создай каталог ./smeta
поставь на нее права r-xr-x--- users:users (это будет аналогом твоей группы smeta)

создай здесь файл ***** с любыми правами и владельцами.

теперь заходим lord-ом.

chmod ./smeta g+w

а затем уже
rm -f ./smeta/****


> Об[ясни мне пожалуйста, что же я делаю "не так"?
Соображаешь не так.

> Заодно и расскажи достопочтенноуважаемой публике, где же ты травы-то
> такой набрал посреди зимы?

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

>Опять же, резервное копирование, восстановление, переезд и прочее такой системы минимально прост: переписать на новый сервер файлы ...

Знаете, меня все еще веселят такие люди :-) Объясните мне, чем процесс отличается при наличии acl на fs?

> Именно ACL'ы создают файлопомойку.

Файлопомойку создают имеенно файлы. Это очевидно, если надо хранить информацию более структурированно, надо использовать другие методы хранения. И acl, ea и просто ugo тут ни при чем :-)

> Файлопомойку создают имеенно файлы.

Ну хоть кто-то догадался, а то acl, acl ...
Это костыль, причём почти никогда не нужный. Минимум можно и группами разрулить, а если нет, начинается acl'апомойка. Раздав "крутые" права через acl порядка не наведёшь. Это не избавит вас, например, от сохранения avi, jpg, mp3 ... Не защитит от файлов .doc с анекдотами. Не систематизирует имена файлов, и многое другое.
В большинстве случаев acl всего лишь бесполезная игрушка. На самом деле пользователям вообще не нужны файлы, на кой ляд хранить письма в word'е? Это к примеру.

Резюмируя. Там где порядок - acl'ы не нужны. Так где бардак - acl'ы не помогут.

>Минимум можно и группами разрулить, а если нет, начинается acl'апомойка.

То, что файлопомойку создают файлы сказал я :-) А вот если Вы не хотите использовать acl- это Ваше личное дело. Может Вы и минет не любите, мне это тоже все равно ;-)

2anonymous (*) (21.02.2004 9:44:55):
Ну ОК:
root@Lord:/# mkdir /assa
root@Lord:/# chown serg.users /assa
root@Lord:/# chmod ug+rx /assa
root@Lord:/# chmod u+w /assa
root@Lord:/# touch /assa/bssa
root@Lord:/# chown serg.users /assa/bssa
root@Lord:/# chmod a-rwx /assa/bssa
root@Lord:/# chmod ug+r /assa/bssa
root@Lord:/# chmod u+w /assa/bssa
...
lord@Lord:/$ chmod g+w /assa/bssa
chmod: изменение прав доступа для `/assa/bssa': Operation not permitted
lord@Lord:/$ chmod g+w /assa
chmod: изменение прав доступа для `/assa': Operation not permitted
lord@Lord:/$ rm -f /assa/bssa
rm: невозможно удалить `/assa/bssa': Permission denied
lord@Lord:/$ rm -fdr /assa
rm: невозможно удалить `/assa': Permission denied

Так эт-та, я опять что-то "не так" сделал? Или где?

Что касается "абстрактного мышления". Уж не знаю, какой у меня уровень абстрактного мышления. Но твердо знаю одно: в вопросе сетевого/системного администрирования уровень "абстрактного мышления" должен быть равен нулю. Сетевое/системное администрирование не предполагает НИКАКОЙ абстракции. Есть только бинарная логика: произошло некоторое событие или нет. В конце-концов, ты со своим "развитым абстрактным мышлением" уже позоришься 2-й день подряд (ну, я полагаю, что твой упрек в мой адрес автоматически означает, что "уровень абстрактного мышления" у тебя развит в несоизмеримо выше, чем у меня).

К anonymous'у нельзя обращаться на ты, только на вы (с маленькой буквы).

Так как пользователю _самому_ определять права на _свои_ файлы?!

Дык теперь все понятно. root оказывается бинарный... matrix has root...

2anonymous (*) (21.02.2004 22:08:16): В случае Самбы это от юзера и не требуется. На шары там можно указывать маски прав на создание файлов/каталогов ("create mask", "directory mask") и даже на владельца/группу ("force user" и "force group", кажется).

не надо путать разные вещи.

2 PitStop:

> Это костыль, причём почти никогда не нужный. Минимум можно и группами разрулить

Расскажите, как мне "разрулить" права доступа к _моим_ файлам "группами"? Или на каждый чих нужно делать su ?

> Раздав "крутые" права через acl порядка не наведёшь. Это не избавит вас, например, от сохранения avi, jpg, mp3 ... Не защитит от файлов .doc с анекдотами.

Discretionary Access Control (DAC) restricts access to objects based on the identity of subjects and/or subject groups. DAC permits the granting and revoking of access privileges to data to be left to the discretion of a user with a certain access permission that has control over the data. However, under privacy aspects, personal data about a data subject should not be "owned" or "controlled" by another person. In order to protect privacy, an access control decision should not be determined by the user's identity, but by the task that the individual user is currently performing. Personal data should only be accessible to a user, if such an access is necessary to perform his/her current task and if he/she is authorised to perform this task (requirement of necessity of data processing).

http://www.rsbac.org/niss98.htm

таки как пользователю _самому_ раздать права на _СВОИ_ файлы?

2 ROOT:

> В случае Самбы это от юзера и не требуется.

К твоему сведению, UNIX используют не только -- и не столько -- как файлопомойку для m$ windoze.

Поэтому вопрос остается -- как пользователь (не root) может раздать права на _СВОИ_ файлы?

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

2 ROOT:

> Но твердо знаю одно: в вопросе сетевого/системного администрирования уровень "абстрактного мышления" должен быть равен нулю.

Чем больше в армии дубов, тем крепче наша оборона.

ROOT — классический образец китайского пионера.

2 ROOT:

> Опять же, резервное копирование, восстановление, переезд и прочее такой системы минимально прост: переписать на новый сервер файлы /etc/shadow, /etc/passwd, /etc/group

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

> и содержимое /pub/projects и /pub/homes, ну и симлинки в автоматическом режиме создать одним-единственным скриптом. Всё.

# newfs -Nv /dev/rdsk/c0t2d0s4

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

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

Dselect - никто тебе не ответит.
Это неудобные вопросы :)

Мне же никто не ответил кроме тебя. И это был acl, а не симлинки на самбе :)

очепятки...

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

Имелось в виду, конечно же,

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

о схожести anonymous'-ов с LOR и службы техподдержки m$

2 jackill:

> Это неудобные вопросы :)

LOR'-овские клоуны поразительно схожи со службой техподдержки m$: вместо ответа на вопрос "Как сделать NNN?" начинают объяснять, что я не хочу делать NNN.

2Dselect (*) (22.02.2004 18:59:43):

1) Ты - бесправный украишка на Российской земле. (это из серии про москалей поганых, только ты еще и тем москалям жопу лижешь.)

2) Все твои подуги оцениваются работодателем менее чем в 3000 рублей (около 110 баксов). Моя зряплатка минимум в 5 раз выше.

3) Ты - аспирантик в Дубне. Ты НИХУЯ даже не видел корпоративных компьютерных сетей. Вот хули ты пиздишь, абормот?

4) Linux - свободная ОС. И каждый рассказывает о _СОБСТВЕННОМ_ опыте реализации конкретных проектов. При чем тут <вместо ответа на вопрос "Как сделать NNN?" начинают объяснять, что я не хочу делать NNN>??? Если тебя интересует как что-то сделать (и, при этом, тебе лень читать документацию) - то плати соответсвующим профессионалам денежку. А _ТРЕБОВАТЬ_ от сообщества ответы - это равносильно требованию подачек в электричках и метро. Это просто позор! Врочем, приблатненые парнишки-аспиранты из Дубны готовы и на позор - лишь бы крутость свою выставить. А вдруг кто и "клюнет"??? Компашка SCO ведет свою политику по тому-же самому принципу.