Re: [Comm] Каталог с совместным доступом

Re: [Comm] Каталог с совместным доступом

[Andrey Rahmatullin]

On Tue, Jan 13, 2009 at 03:57:51PM +0300, Yury Aliaev wrote:
> (wife). Мы решили создать отдельный каталог, куда будем складывать  
> фотографии. Причём нужно, чтобы и я, и жена могли делать всё, что  
> захочется с его содержимым
Опять???

[Comm] Каталог с совместным доступом

[Yury Aliaev]

Приветствую уважаемое сообщество!

У меня возникла проблемка, на решение которой моих знаний unix не 
хватает. Хотя проблемка на первый взгляд элементарная... В общем, на 
моём домашнем компе два пользователя -- я (скажем условно, me) и жена 
(wife). Мы решили создать отдельный каталог, куда будем складывать 
фотографии. Причём нужно, чтобы и я, и жена могли делать всё, что 
захочется с его содержимым (в смысле добавлять файлы, каталоги, читать, 
копировать, удалять). Тут-то и встала проблема. Я решил действовать 
следующим образом. Во-первых, создал у себя в /home/me каталог photos, а 
в /home/wife для удобства ссылочку на него кинул. Во-вторых, создал 
группу photo, куда внёс себя с женой. А в-третьих, сменил группу у 
/home/me/photos на photo и дал право группе на запись. На первый взгляд 
сработало, и жена, и я можем туда файлы класть и подкаталоги создавать. 
Только вот владелец и группа у подкаталогов не наследуются от 
родительского каталога. В общем, кто подкаталог создал, тот и может туда 
файлы класть да удалять оттуда... Подумал малость, добавил sticky бит у 
/home/me/photos. Вроде как группа у подкаталогов стала теперь photos, да 
только вот права на запись для группы у подкаталогов всё равно нет... И 
как решить проблему не знаю, возможно, плутая в трёх соснах.

Если кто поможет советом -- большое спасибо!

Удачи!
Юрий.

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Yury Aliaev пишет:
> Приветствую уважаемое сообщество!

> /home/me/photos. Вроде как группа у подкаталогов стала теперь photos, да 
> только вот права на запись для группы у подкаталогов всё равно нет... И 
> как решить проблему не знаю, возможно, плутая в трёх соснах.
> 
#chown -R :photos /home/me/photos
#chmod g+s /home/me/photos

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

13 января 2009 г. 15:57 пользователь Yury Aliaev <mutab0r@rambler.ru> написал:
> Приветствую уважаемое сообщество!
>
> У меня возникла проблемка, на решение которой моих знаний unix не хватает.
> Хотя проблемка на первый взгляд элементарная... В общем, на моём домашнем
> компе два пользователя -- я (скажем условно, me) и жена (wife). Мы решили
> создать отдельный каталог, куда будем складывать фотографии. Причём нужно,
> чтобы и я, и жена могли делать всё, что захочется с его содержимым (в смысле
> добавлять файлы, каталоги, читать, копировать, удалять). Тут-то и встала
> проблема. Я решил действовать следующим образом. Во-первых, создал у себя в
> /home/me каталог photos, а в /home/wife для удобства ссылочку на него кинул.
> Во-вторых, создал группу photo, куда внёс себя с женой. А в-третьих, сменил
> группу у /home/me/photos на photo и дал право группе на запись. На первый
> взгляд сработало, и жена, и я можем туда файлы класть и подкаталоги
> создавать. Только вот владелец и группа у подкаталогов не наследуются от
> родительского каталога. В общем, кто подкаталог создал, тот и может туда
> файлы класть да удалять оттуда... Подумал малость, добавил sticky бит у
> /home/me/photos. Вроде как группа у подкаталогов стала теперь photos, да
> только вот права на запись для группы у подкаталогов всё равно нет... И как
> решить проблему не знаю, возможно, плутая в трёх соснах.
>
> Если кто поможет советом -- большое спасибо!
К сожалению, никак. Это типичная проблема с правами доступа в UNIX.
Единственная по-настоящему работающая рекомендация, которая мне
попадалась, это раздать каталог, через самбу, и заставить ее всех
пользователей сбрасывать в одного (или работать от анонимного
пользователя).

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Igor Vlasenko]

On Tue, Jan 13, 2009 at 03:57:51PM +0300, Yury Aliaev wrote:
> Приветствую уважаемое сообщество!
> файлы класть да удалять оттуда... Подумал малость, добавил sticky бит у  
> /home/me/photos. Вроде как группа у подкаталогов стала теперь photos, да  
> только вот права на запись для группы у подкаталогов всё равно нет... И  
> как решить проблему не знаю, возможно, плутая в трёх соснах.

Здесь еще не хватает правильного umask. 
У вас с супругой umask 022, а надо 002.

К сожалению, выставить всюду правильный umask нет царского пути.

Вот как это сделать в KDE:
http://linux.derkeiler.com/Mailing-Lists/KDE/2007-05/msg00004.html

P.S.
Юрий, с вас новый libquicktime :)

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [Comm] Каталог с совместным доступом

[Igor Vlasenko]

On Tue, Jan 13, 2009 at 03:23:05PM +0200, Igor Vlasenko wrote:
> On Tue, Jan 13, 2009 at 03:57:51PM +0300, Yury Aliaev wrote:
> > Приветствую уважаемое сообщество!
> > файлы класть да удалять оттуда... Подумал малость, добавил sticky бит у  
> > /home/me/photos. Вроде как группа у подкаталогов стала теперь photos, да  
> > только вот права на запись для группы у подкаталогов всё равно нет... И  
> > как решить проблему не знаю, возможно, плутая в трёх соснах.
> 
> Здесь еще не хватает правильного umask. 
> У вас с супругой umask 022, а надо 002.
> 
> К сожалению, выставить всюду правильный umask нет царского пути.

Сорри, как раз есть царский путь.
Нужно воспользоваться pam_umask :)

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [Comm] Каталог с совместным доступом

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

Yury Aliaev <mutab0r-HPQIj1OAFZMvJsYlp49lxw@public.gmane.org> writes:

> Приветствую уважаемое сообщество!
>
> У меня возникла проблемка, на решение которой моих знаний unix не
> хватает. Хотя проблемка на первый взгляд элементарная... В общем, на
> моём домашнем компе два пользователя -- я (скажем условно, me) и жена
> (wife). Мы решили создать отдельный каталог, куда будем складывать
> фотографии. Причём нужно, чтобы и я, и жена могли делать всё, что
> захочется с его содержимым (в смысле добавлять файлы, каталоги,
> читать, копировать, удалять). Тут-то и встала проблема. Я решил
> действовать следующим образом. Во-первых, создал у себя в /home/me
> каталог photos, а в /home/wife для удобства ссылочку на него
> кинул.
Ну я для начала создавал бы этот каталог ВНЕ личных каталогов
пользователей.

> Если кто поможет советом -- большое спасибо!
Ну либо использовать самбу, либо ACL.

PS: Я делал такое на ACL и оно точно работает.

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

13 января 2009 г. 18:08 пользователь Ivan Fedorov <ns@altlinux.org> написал:
> PS: Я делал такое на ACL и оно точно работает.
Поделитесь рецептом? А то я пока считаю, что они даже такого простого
действия не могут.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Sergey Shilov]

В сообщении от 13 января 2009 Yury Aliaev написал(a):

> У меня возникла проблемка, на решение которой моих знаний unix не 
> хватает. Хотя проблемка на первый взгляд элементарная...
> В общем, на  
> моём домашнем компе два пользователя -- я (скажем условно, me) и жена 
> (wife). Мы решили создать отдельный каталог, куда будем складывать 
> фотографии. Причём нужно, чтобы и я, и жена могли делать всё, что 
> захочется с его содержимым (в смысле добавлять файлы, каталоги, читать, 
> копировать, удалять). 
> Если кто поможет советом -- большое спасибо!

Если очень хочется шары (воспринимать с долей юмора)  ... 

Пользуем локальный анонимный nfs с подменой пользователя.


Через sudo или из под рута

Ставим nfs (клиент и сервер)
#apt-get install nfs-clients nfs-utils nfs-server

Настраиваем локальный nfs сервер

Готовим каталог для шары
#mkdir /home/shared
#chown nobody.nobody /home/shared

Разрешаем локальный доступ (можно уточнять)
#echo -e "ALL: 127.0.0.1\n">>/etc/hosts.allow
 
Разрешаем монтирование /home/shared  по nfs 
#echo -e "/home/shared       127.0.0.1/255.255.255.0(rw,all_squash,anonuid=99,anongid=99)\n">>/etc/exports
Тут 99 это UID и GID пользователя nobody

Включаем nfs 
#chkconfig nfs on

Рестартуем nfs 
#service nfs restart


Настраиваем клиента для раздачи nfs-ной шары 

Готовим каталог(и) 
#mkdir /mnt/shared
Алкающим шары пользователям можно самостоятельно в ~ сделать симлинки на /mnt/shared
$ln -s /mnt/shared/ ~/shared

Настраиваем монтирование (noauto - из-за того, что будем костылем монтировать у себя)
#echo -e "localhost:/home/shared          /mnt/shared             nfs     rw,nolock,noauto  0 0\n">>/etc/fstab
Собственно "костыль"
#touch /etc/rc.d/rc.local
#chmod 700 /etc/rc.d/rc.local
#echo -e "mount localhost:/home/shared\n">>/etc/rc.d/rc.local 

Передергиваем портмап 
#service portmap restart

Монтируем
#mount /mnt/shared



В результате в каждый желающий может читать/писать/ваять
в каталоге  ~/shared, который реально есть 
/home/shared с правами на все nobody.nobody

 
---
С уважением
С.Шилов

Re: [Comm] Каталог с совместным доступом

[Denis Nazarov]

On Tuesday 13 January 2009 20:55:56 Sergey Shilov wrote:
> Если очень хочется шары (воспринимать с долей юмора)  ...

я, наверное, просто не выспался, но где тут юмор? может на вики? или в FAQ?

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

13 января 2009 г. 19:07 пользователь Denis Nazarov <marsden@mail.ru> написал:
> я, наверное, просто не выспался, но где тут юмор? может на вики? или в FAQ?
Вот-вот. Мне тоже не смешно от того, что такая простая задача требует
так много усилий и решается такими костылями.

Есть еще вариант с vfat в файле, который монтируется как loop-устройство

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

"Dmitriy M. Maslennikov"
<maslennikovdm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> 13 января 2009 г. 18:08 пользователь Ivan Fedorov <ns@altlinux.org> написал:
>> PS: Я делал такое на ACL и оно точно работает.
> Поделитесь рецептом? А то я пока считаю, что они даже такого простого
> действия не могут.
Ну надо просто использовать default acl's:

[root@storage ~]# cd /srv
[root@storage srv]# mkdir -p shared-test
[root@storage srv]# chmod 0700 shared-test
[root@storage srv]# getfacl shared-test  
# file: shared-test
# owner: root
# group: root
user::rwx
group::---
other::---

[oxyum@storage ~]$ cd /srv/shared-test/
-bash: cd: /srv/shared-test/: Отказано в доступе


[root@storage srv]# mount -o remount,acl /
[root@storage srv]# setfacl -m u:oxyum:rwX shared-test 
[root@storage srv]# setfacl -m u:user2:rwX shared-test 
[root@storage srv]# getfacl --access shared-test/ | setfacl -d -M- shared-test/
[root@storage srv]# getfacl -R shared-test
# file: shared-test
# owner: root
# group: root
user::rwx
user:oxyum:rwx
user:user2:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:oxyum:rwx
default:user:user2:rwx
default:group::---
default:mask::rwx
default:other::---


[oxyum@storage shared-test]$ mkdir user1

[root@storage srv]# getfacl -R shared-test
# file: shared-test
# owner: root
# group: root
user::rwx
user:oxyum:rwx
user:user2:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:oxyum:rwx
default:user:user2:rwx
default:group::---
default:mask::rwx
default:other::---

# file: shared-test/user1
# owner: oxyum
# group: oxyum
user::rwx
user:oxyum:rwx
user:user2:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:oxyum:rwx
default:user:user2:rwx
default:group::---
default:mask::rwx
default:other::---


[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

2009/1/13 Ivan Fedorov <ns@altlinux.org>:
> "Dmitriy M. Maslennikov"
> <maslennikovdm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> 13 января 2009 г. 18:08 пользователь Ivan Fedorov <ns@altlinux.org> написал:
>>> PS: Я делал такое на ACL и оно точно работает.
>> Поделитесь рецептом? А то я пока считаю, что они даже такого простого
>> действия не могут.
> Ну надо просто использовать default acl's:
Про default acl знаю. Не знаю, как победить следующую проблему: если
файл копируется с ro носителя (cd с фотографиями), то права владельца
r-x и маска тоже сбразывается на r-x, в результате получаем
невозможность редактирования для всех.

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

А кто-нибудь знает fs под линукс с нормальной раздачей прав?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Andriy Dobrovol`s`kii]

2009/1/13 Dmitriy M. Maslennikov <maslennikovdm@>:
>
> Есть еще вариант с vfat в файле, который монтируется как loop-устройство
>
А какие права у Вас на каталоги и файлы в этом общем каталоге?
А простого решения нет т.к. сама задача слегка "подрывает" принципы
построения системы.
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

13 января 2009 г. 21:20 пользователь Andriy Dobrovol`s`kii
<adobrovolskii@gmail.com> написал:
> 2009/1/13 Dmitriy M. Maslennikov <maslennikovdm@>:
>>
>> Есть еще вариант с vfat в файле, который монтируется как loop-устройство
>>
> А какие права у Вас на каталоги и файлы в этом общем каталоге?
> А простого решения нет т.к. сама задача слегка "подрывает" принципы
> построения системы.
У меня? Никаких.

С самого начала задача ставилась как организация директории, к
которой, а равно как и ко всем вложенным объектам, указанные
пользователи будут иметь полный доступ. То есть права должны на все
быть полными и сохранятся такими без дополнительных телодвижений,
чтобы "случайно" там не оказывались объекты, на которые у указанных
пользователей нет прав.

А никакие принципы системы не должны мешать людям жить и работать.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

"Dmitriy M. Maslennikov"
<maslennikovdm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> 2009/1/13 Ivan Fedorov <ns@altlinux.org>:
>> "Dmitriy M. Maslennikov"
>> <maslennikovdm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>>> 13 января 2009 г. 18:08 пользователь Ivan Fedorov <ns@altlinux.org> написал:
>>>> PS: Я делал такое на ACL и оно точно работает.
>>> Поделитесь рецептом? А то я пока считаю, что они даже такого простого
>>> действия не могут.
>> Ну надо просто использовать default acl's:
> Про default acl знаю. Не знаю, как победить следующую проблему: если
> файл копируется с ro носителя (cd с фотографиями), то права владельца
> r-x и маска тоже сбразывается на r-x, в результате получаем
> невозможность редактирования для всех.

хм... вы можете мне в личку написать что точно у вас не получается - я
попробую поиграться тогда. :)

А то рассылки я часто не дочитываю...

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [Comm] Каталог с совместным доступом

[Andrey Alexandrov]

Когда то стояла такая проблема. Решил на скорую руку с помощью
грубейшего костыля, в виде acl + crontab. С тех пор так и работает.
-- 
С ув. Андрей Александров

Re: [Comm] Каталог с совместным доступом

[Sergey Shilov]

On Tuesday 13 January 2009 18:07:47 Denis Nazarov wrote:
> On Tuesday 13 January 2009 20:55:56 Sergey Shilov wrote:
> > Если очень хочется шары (воспринимать с долей юмора)  ...
>
> я, наверное, просто не выспался, но где тут юмор? 
В несколько "неформальном" тоне. 
> может на вики? или в FAQ? 
Может (подправив). Если общественнось сочтет достойным.

-- 
С уважением
Сергей Шилов.

Re: [Comm] Каталог с совместным доступом

[Sergey Shilov]

On Tuesday 13 January 2009 18:25:22 Ivan Khakhaev wrote:

> Я конечно, дико извиняюсь, я не такой крутой ИТ-шник, но не проще ли
> сделать каталог в разделе в vfat?
Проще. Если есть раздел в vfat :-)
Есть подозрение, что после ответа про раздел ФАТ будет вопрос о его создании.  

-- 
С уважением
Сергей Шилов.

Re: [Comm] Каталог с совместным доступом

[Sergey Shilov]

On Tuesday 13 January 2009 18:24:42 Dmitriy M. Maslennikov wrote:

> Вот-вот. Мне тоже не смешно от того, что такая простая задача 
Она (задача) только в постановке простая.
Тема в рассылках уже обсуждалась (см. реакцию wrar@ :-))
> требует так много усилий и решается такими костылями.
По большому счету в предложенном варианте реальный костыль только один (с 
rc.local) и он не связан с задачей. 
> Есть еще вариант с vfat в файле, который монтируется как loop-устройство
Есть. Самба есть. ACL есть. 
Инструкции  в студию. 
Путь люди выбирают.

-- 
С уважением
Сергей Шилов.

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

13 января 2009 г. 23:09 пользователь Sergey Shilov <hsvhome@mail.ru> написал:
>> Вот-вот. Мне тоже не смешно от того, что такая простая задача
> Она (задача) только в постановке простая.
Она и в реализации простая, если бы POSIX стандарт на ACL был бы более
разумным. Глупо это отрицать. Управление доступом в более других ОС
куда проще. Глупо отрицать очевидные недостатки.

> Тема в рассылках уже обсуждалась (см. реакцию wrar@ :-))
Тему и я неоднократно поднимал. Не надо меня посылать в рассылки, я в
обсуждениях участвовал.

> По большому счету в предложенном варианте реальный костыль только один (с
> rc.local) и он не связан с задачей.
Реальный костыль - это при невозможности гибко управлять правами
работа с файлами через сеть (пусть и lo интерфейс). Впрочем чуть более
сложные задачи этим не решаются.

>> Есть еще вариант с vfat в файле, который монтируется как loop-устройство
> Есть. Самба есть. ACL есть.
Самба есть, но это тоже только для простейших случаев.

ACL почти ничего не могут, даже простую задачу дать весь подкаталог всем.

Если есть сомнения решите такую задачку:

Организовать директорию со следующими свойствами:
- Школьники (группа) могут создавать внутри нее создавать файлы и
каталоги произвольной вложенности
- Школьники могут читать все файлы и каталоги
- Школьники могут удалять и редактировать только свои файл и каталоги
- Учитель может читать, удалять, редактировать все файлы и директории,
созданные учениками
- Учитель может создавать внутри файлы и каталоги доступные как только
для чтения, так и для записи как всем ученикам, так и только избранным
- Администратор может читать, удалять, редактировать все файлы и каталоги
- Администратор может создать файлы и каталоги доступные как только
для чтения, так и для записи как всем ученикам, так и избранным, так и
учителю

Решите, пожалуйста, эту правдоподобную, на мой взгляд, задачку. Кроме
того, Школьников можно заменить на сотрудников, учителя на директора,
а дополнительно ввести бугалтеров и начальников отделов и еще
поиграться с задачкой.

> Инструкции  в студию.
А нет их, почти.

> Путь люди выбирают.
В случае задачи гибкого управления правами в файловой системе выбирать
придется платные решения.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Sergey Shilov]

On Tuesday 13 January 2009 22:33:01 Dmitriy M. Maslennikov wrote:

> Управление доступом в более других ОС куда проще. 
Возможно, но здесь @lists.altlinux.org
> Глупо отрицать очевидные недостатки. 
Я просто предложил практический ответ на конкретный вопрос.

> > Тема в рассылках уже обсуждалась (см. реакцию wrar@ :-))
> Тему и я неоднократно поднимал. Не надо меня посылать в рассылки, 
Никого и никуда не посылали. Имелся ввиду второй пост ветки.
wrar@ прав. 

-- 
С уважением
Сергей Шилов.

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 1:20 пользователь Sergey Shilov <hsvhome@mail.ru> написал:
>> Управление доступом в более других ОС куда проще.
> Возможно, но здесь @lists.altlinux.org
>> Глупо отрицать очевидные недостатки.
> Я просто предложил практический ответ на конкретный вопрос.
Если вы вниательно читали тему, то видели, что первым своим сообщением
(второй ответ в ветке вообще), я дал понять человеку, что вопрос для
линуксе не элементарен (он жаловался, что не знает линукс настолько
хорошо, чтобы решить проблему, хотя проблема элементарная) и сразу
предложил ему костыль, который далее и разжевали.

>> > Тема в рассылках уже обсуждалась (см. реакцию wrar@ :-))
>> Тему и я неоднократно поднимал. Не надо меня посылать в рассылки,
> Никого и никуда не посылали. Имелся ввиду второй пост ветки.
> wrar@ прав.
Ответ "нет"? В том, что недостатки линикса здесь offtop? Или что
пользователям коммунити не стоит знать, в каких случаях им с линуксом
не попути? Или в чем он прав, может мы о разных ветках?

Просто подобные вопросы часто задаются. И я считаю, что вместо того,
чтобы с умным видом рассказывать человеку, что он не правильно ставит
задачу и вообще хочет странного гораздо лучше признать, что в этом
месте Linux никуда не годен. Причем сразу, чтобы пользователя по мере
изучения не ждало ужасное разочарование. Он хорош во многих местах, но
не в управлении правами доспупа в файловой системе, поэтому, если
такая задача стоит, надо использовать другие инструменты.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Serge]

Sergey Shilov пишет:
> On Tuesday 13 January 2009 18:25:22 Ivan Khakhaev wrote:
>
>   
>> Я конечно, дико извиняюсь, я не такой крутой ИТ-шник, но не проще ли
>> сделать каталог в разделе в vfat?
>>     
> Проще. Если есть раздел в vfat :-)
> Есть подозрение, что после ответа про раздел ФАТ будет вопрос о его создании.  
>
>   
Ребята, как мне кажется это вообще не задача файловой системы или 
системы в целом.
Здесь просто необходима прослойка между пользователями и файловой 
системой(читай хранилищем)
Для задач а-ля школьники/сотрудники в настоящее время используются 
соответствующие программы типа там документооборота итд. Вот в какую 
сторону надо смотреть.

Как по мне, то можно поднять на локалке сайтец, который будет 
упорядочено показывать содержимое каталога и иметь функционал CRUD 
(create read update delete) и все.
Остальное от лукавого...

Re: [Comm] Каталог с совместным доступом

[Aleksander N. Gorohovski]

On Wed, 14 Jan 2009 08:36:54 +0200, Dmitriy M. Maslennikov  
<maslennikovdm@gmail.com> wrote:

<skipped>

> Просто подобные вопросы часто задаются. И я считаю, что вместо того,
> чтобы с умным видом рассказывать человеку, что он не правильно ставит
> задачу и вообще хочет странного гораздо лучше признать, что в этом
> месте Linux никуда не годен. Причем сразу, чтобы пользователя по мере
> изучения не ждало ужасное разочарование. Он хорош во многих местах, но
> не в управлении правами доспупа в файловой системе, поэтому, если

Странно,
Как по мне, то с 1985г. лучшей системы управления, чем *nix пока не  
встретилось

> такая задача стоит, надо использовать другие инструменты.

Например,
?

Re: [Comm] Каталог с совместным доступом

[Владимир]

> > Если кто поможет советом -- большое спасибо!
>
> К сожалению, никак. Это типичная проблема с правами доступа в UNIX.
> Единственная по-настоящему работающая рекомендация, которая мне
> попадалась, это раздать каталог, через самбу, и заставить ее всех
> пользователей сбрасывать в одного (или работать от анонимного
> пользователя).


можно крону поручить +w группе ставить, можно при входе пользователя 
из .bash_profile  от скрипт с рутовыми правами запускать....

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 10:42 пользователь Aleksander N. Gorohovski
<angel@feht.dgtu.donetsk.ua> написал:
> Странно,
> Как по мне, то с 1985г. лучшей системы управления, чем *nix пока не
> встретилось
Ну так решите приведенную задачку.

>> такая задача стоит, надо использовать другие инструменты.
>
> Например,
> ?
Например операционные системы от Microsoft.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 10:36 пользователь Serge <serg-e@ukr.net> написал:
> Ребята, как мне кажется это вообще не задача файловой системы или системы в
> целом.
> Здесь просто необходима прослойка между пользователями и файловой
> системой(читай хранилищем)
> Для задач а-ля школьники/сотрудники в настоящее время используются
> соответствующие программы типа там документооборота итд. Вот в какую сторону
> надо смотреть.
Не надо в эту сторону смотреть. При обучении школьники (студенты)
должны проходить работу с файловой системой, создавать файлы с
учебными программами, скриптами. Все это держать в документообороте
неудобно. Программы еще и компилировать надо. В общем без файлов
никуда.

> Как по мне, то можно поднять на локалке сайтец, который будет упорядочено
> показывать содержимое каталога и иметь функционал CRUD (create read update
> delete) и все.
> Остальное от лукавого...
И научить gcc компилировать программы, забирая их с сайта и заливая
туда результат, минуя ФС, ага, еще что предложите?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Yury Aliaev]

Sergey Shilov пишет:

> 
>> Вот-вот. Мне тоже не смешно от того, что такая простая задача 
> Она (задача) только в постановке простая.

Да, значит дело всё-таки не в моём незнании... Что ж, спасибо всем, кто 
мне ответил, скажу сразу, что в моём случае геморрой не стоит свеч и я 
поступлю проще, отдам весь каталог жене и если мне там понадобится 
что-то поменять, буду под ней заходить.

> Тема в рассылках уже обсуждалась (см. реакцию wrar@ :-))

Да что ещё ожидать от штатного тролля...

P.S. Для Игоря Власенко -- новый libquicktime сделаю как только 
заработают механизмы, обеспечивающие выполнение условий из соглашения о 
разделяемых библиотеках. Или они уже работают?

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 11:02 пользователь Владимир <haw@inbox.ru> написал:
> можно крону поручить +w группе ставить, можно при входе пользователя
> из .bash_profile  от скрипт с рутовыми правами запускать....
"...плакали, кололись, но продолжали грызть кактус..."

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 12:24 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
>> Как по мне, то можно поднять на локалке сайтец, который будет упорядочено
>> показывать содержимое каталога и иметь функционал CRUD (create read update
>> delete) и все.
>> Остальное от лукавого...
> И научить gcc компилировать программы, забирая их с сайта и заливая
> туда результат, минуя ФС, ага, еще что предложите?
Еще и каждого учителя обучаем писать сайты... Вместо того, чтобы
просто настроить права доступа. Вы представляете насколько по
трудозатратам отличается поднятие сайта от правки ACL в случае того же
Windows? Да и по удобству работы ни в какое сравнение не идет, когда
нужен не обмен файлами, не выкладывание, не документооборот, а именно
работа с файлами.

>
> --
> Dmitriy M. Maslennikov
> rlz@etersoft.ru
> rlz@altlinux.org
> maslennikovdm@gmail.com
> master@armory.ru
>



-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Yury Aliaev пишет:
> Sergey Shilov пишет:

> Да, значит дело всё-таки не в моём незнании... Что ж, спасибо всем, кто 
> мне ответил, скажу сразу, что в моём случае геморрой не стоит свеч и я 
> поступлю проще, отдам весь каталог жене и если мне там понадобится 
> что-то поменять, буду под ней заходить.

Да задача в самом деле простая.
Вас вводят в заблуждение.
Решается в рамках стандартных групповых политик назначением "s"-бита для 
группы в каталоге.
После установки этого бита файлы в этом каталоге создаются не с правами 
login group владельца файла, а с группой каталога.

Я написал те две строчки, которые это делают, но Вы видимо их не заметили:

Gennadii Redko пишет:
<skip>
 > #chown -R :photos /home/me/photos
 > #chmod g+s /home/me/photos



Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...

Re: [Comm] Каталог с совместным доступом

[Serge]

Dmitriy M. Maslennikov пишет:
> 14 января 2009 г. 12:24 пользователь Dmitriy M. Maslennikov
> <maslennikovdm@gmail.com> написал:
>   
>>> Как по мне, то можно поднять на локалке сайтец, который будет упорядочено
>>> показывать содержимое каталога и иметь функционал CRUD (create read update
>>> delete) и все.
>>> Остальное от лукавого...
>>>       
>> И научить gcc компилировать программы, забирая их с сайта и заливая
>> туда результат, минуя ФС, ага, еще что предложите?
>>     
> Еще и каждого учителя обучаем писать сайты... Вместо того, чтобы
> просто настроить права доступа. Вы представляете насколько по
> трудозатратам отличается поднятие сайта от правки ACL в случае того же
> Windows? Да и по удобству работы ни в какое сравнение не идет, когда
> нужен не обмен файлами, не выкладывание, не документооборот, а именно
> работа с файлами.
>
>   
Вы меня не слышите...

Я описал ВАРИАНТ решения КОНКРЕТНОЙ задачи а не панацею...

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Gennadii Redko <uit1 zaz.zp.ua>:
> Yury Aliaev пишет:
> Да задача в самом деле простая.
> Вас вводят в заблуждение.
> Решается в рамках стандартных групповых политик назначением "s"-бита для
> группы в каталоге.
> После установки этого бита файлы в этом каталоге создаются не с правами
> login group владельца файла, а с группой каталога.
>
> Я написал те две строчки, которые это делают, но Вы видимо их не заметили:
>
> Gennadii Redko пишет:
> <skip>
>> #chown -R :photos /home/me/photos
>> #chmod g+s /home/me/photos
Это один, не самый простой вариант
>
> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
Вот-вот... А не проще ли...
groupadd family
usermod -g family me
usermod -g family wife
mkdir /home/exchange
chgrp family /home/exchange
sed 's|umask 022|umask 002|' /etc/profile
...сделать раз и навсегда?

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 13:02 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>> Да, значит дело всё-таки не в моём незнании... Что ж, спасибо всем, кто
>> мне ответил, скажу сразу, что в моём случае геморрой не стоит свеч и я
>> поступлю проще, отдам весь каталог жене и если мне там понадобится что-то
>> поменять, буду под ней заходить.
> Да задача в самом деле простая.
> Вас вводят в заблуждение.
> Решается в рамках стандартных групповых политик назначением "s"-бита для
> группы в каталоге.
> После установки этого бита файлы в этом каталоге создаются не с правами
> login group владельца файла, а с группой каталога.
>
> Я написал те две строчки, которые это делают, но Вы видимо их не заметили:
>
> Gennadii Redko пишет:
> <skip>
>> #chown -R :photos /home/me/photos
>> #chmod g+s /home/me/photos
>
> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
Вас и правда вводят в заблуждение. Начнем с того, что фотографии вы
наверняка будете разбирать по каталогам, а не валить в одну кучу,
поэтому придется выставлять права, что можно делать и без всякого
s-бита. А закончим тем, что вам придется сменить права, с которыми
создаются файлы по-умолчанию (иначе файлы не будут доступны группе на
запись), причем настройка эта глобальная для всей файловой системы,
что понизит безопасность в остальных частях файловой системы.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Yury Aliaev]

Gennadii Redko пишет:

> 
>> Да, значит дело всё-таки не в моём незнании... Что ж, спасибо всем, 
>> кто мне ответил, скажу сразу, что в моём случае геморрой не стоит свеч 
>> и я поступлю проще, отдам весь каталог жене и если мне там понадобится 
>> что-то поменять, буду под ней заходить.
> 
> Да задача в самом деле простая.
> Вас вводят в заблуждение.
> Решается в рамках стандартных групповых политик назначением "s"-бита для 
> группы в каталоге.
> После установки этого бита файлы в этом каталоге создаются не с правами 
> login group владельца файла, а с группой каталога.
> 
> Я написал те две строчки, которые это делают, но Вы видимо их не заметили:
> 
> Gennadii Redko пишет:
> <skip>
>  > #chown -R :photos /home/me/photos
>  > #chmod g+s /home/me/photos
> 

Увы, не работает. Я так пытался (возможно, что не чётко сформулировал в 
ответе). Получается следующее: подкаталоги создаются с владельцем либо 
me, либо wife в зависимости от того, кто создавал, и с группой photos. 
НО! Прав на записи для группы у подкаталогов по умолчанию нет. Т.е. при 
создании каждого подкаталога нужно говорить "chmod g+w subdir" (или 
аналогичное действие в каком-нибудь файловом менеджере). А хотелось как 
раз обойтись без групповухи.

> 
> 
> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...

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

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:

>>> такая задача стоит, надо использовать другие инструменты.
>> Например,
>> ?
> Например операционные системы от Microsoft.
> 
Знаете, если не владеете возможностями инструмента обсуждаемого в этой 
рассылке - не давайте советов.
Тем более таких "радикальных".
"Постойте-покурите" в сторонке.
Может быть найдется тот, кто даст более компетентный ответ.

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 13:10 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> Это один, не самый простой вариант
>>
>> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
> Вот-вот... А не проще ли...
> groupadd family
> usermod -g family me
> usermod -g family wife
> mkdir /home/exchange
> chgrp family /home/exchange
> sed 's|umask 022|umask 002|' /etc/profile
> ...сделать раз и навсегда?
Что сделает все файлы общими, а не только находящиеся в
/home/exchange, и еще больше снизит безопасность

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 13:13 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>> Например операционные системы от Microsoft.
> Знаете, если не владеете возможностями инструмента обсуждаемого в этой
> рассылке - не давайте советов.
Знаете, в сфере обсуждаемых здесь вопросов, владею в равной степени и
Linux и Windows.

Под linux нормального решения нет. Автор вопроса выбрал вполне
логичный путь - работать из-под одного пользователя, так как дома это
не критично. На работе в таких задачах приметить Linux, к сожалению,
как минимум ПОКА не получиться.

> Тем более таких "радикальных".
> "Постойте-покурите" в сторонке.
> Может быть найдется тот, кто даст более компетентный ответ.
Уже несколько лет как не нашелся... Можно только модуль ядра написать,
т. е. подхачить саму систему безопасности, а вот административными
методами никак.

Да и не надо тут обсуждать меня. Лучше предложите нормальное решение
если можете, а если нет, то просто ждите, пока не найдется тот, кто
решит проблему.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Yury Aliaev пишет:
> Gennadii Redko пишет:
> 
>>
>>> Да, значит дело всё-таки не в моём незнании... Что ж, спасибо всем, 
>>> кто мне ответил, скажу сразу, что в моём случае геморрой не стоит 
>>> свеч и я поступлю проще, отдам весь каталог жене и если мне там 
>>> понадобится что-то поменять, буду под ней заходить.
>>
>> Да задача в самом деле простая.
>> Вас вводят в заблуждение.
>> Решается в рамках стандартных групповых политик назначением "s"-бита 
>> для группы в каталоге.
>> После установки этого бита файлы в этом каталоге создаются не с 
>> правами login group владельца файла, а с группой каталога.
>>
>> Я написал те две строчки, которые это делают, но Вы видимо их не 
>> заметили:
>>
>> Gennadii Redko пишет:
>> <skip>
>>  > #chown -R :photos /home/me/photos
>>  > #chmod g+s /home/me/photos
>>
> 
> Увы, не работает. Я так пытался (возможно, что не чётко сформулировал в 
> ответе). Получается следующее: подкаталоги создаются с владельцем либо 
> me, либо wife в зависимости от того, кто создавал, и с группой photos. 
> НО! Прав на записи для группы у подкаталогов по умолчанию нет. Т.е. при 
> создании каждого подкаталога нужно говорить "chmod g+w subdir" (или 
> аналогичное действие в каком-нибудь файловом менеджере). А хотелось как 
> раз обойтись без групповухи.
> 
>>
>>
>> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
> 
> Он как раз добавляется автоматически. Не добавляется бит записи для группы.
Измените тогда umask по совету Евгения Остапца.
Но лучше не для умолчательного профиля, а для профилей пользователей me 
и wife.

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 13:10 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
>> Это один, не самый простой вариант
>>>
>>> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
>> Вот-вот... А не проще ли...
>> groupadd family
>> usermod -g family me
>> usermod -g family wife
>> mkdir /home/exchange
>> chgrp family /home/exchange
>> sed 's|umask 022|umask 002|' /etc/profile
>> ...сделать раз и навсегда?
> Что сделает все файлы общими, а не только находящиеся в
> /home/exchange, и еще больше снизит безопасность
Общими??? Не курите больше эту траву!
Эта маска означает, что файлы будут доступны на запись ГРУППЕ, а у нас
по-умолчанию для каждого пользователя создается СОБСТВЕННАЯ группа! В
предложенном решении файлы будут доступны группе family в которой два
пользователя - то, что и требовалось. Владельцами домашнего каталоге
по-прежнему будут me:me, т.е. wife не доберется до компромата!


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:
> 14 января 2009 г. 13:13 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>>> Например операционные системы от Microsoft.
>> Знаете, если не владеете возможностями инструмента обсуждаемого в этой
>> рассылке - не давайте советов.
> Знаете, в сфере обсуждаемых здесь вопросов, владею в равной степени и
> Linux и Windows.
Хорошо, а как бы Вы решили данную задачу по виндовс?
Там ведь те же проблемы с масками и умолчательными правами для каталогов.
Проблема упирается в подходы предоставления прав доступа файлам, а не в 
различия их реализаций.

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 13:20 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> Общими??? Не курите больше эту траву!
Не курю. Я не сказал "общими для всех". Проблема в том, что так все
файлы, созданные после этих изменений указанными пользователями, сразу
оказываюстся доступными для всей группы family по-умолчанию, что
является нежелательным побочным эффектом снижающим безопасность. Так
понятнее?

> Эта маска означает, что файлы будут доступны на запись ГРУППЕ, а у нас
> по-умолчанию для каждого пользователя создается СОБСТВЕННАЯ группа! В
> предложенном решении файлы будут доступны группе family в которой два
> пользователя - то, что и требовалось. Владельцами домашнего каталоге
> по-прежнему будут me:me, т.е. wife не доберется до компромата!
Вы так говорите, будто не видите проблем. Если потом раздать в локалку
фотографии и дать права просмотра группе family, то случайно можно
раздать совсем лишнюю информацию. Такое снижение безопасности очень
неприятно.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 13:20 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
>> Общими??? Не курите больше эту траву!
> Не курю. Я не сказал "общими для всех". Проблема в том, что так все
> файлы, созданные после этих изменений указанными пользователями, сразу
> оказываюстся доступными для всей группы family по-умолчанию, что
> является нежелательным побочным эффектом снижающим безопасность. Так
> понятнее?
Абсолютно непонятно, у нас с вами разные представления о безопасности...
>
>> Эта маска означает, что файлы будут доступны на запись ГРУППЕ, а у нас
>> по-умолчанию для каждого пользователя создается СОБСТВЕННАЯ группа! В
>> предложенном решении файлы будут доступны группе family в которой два
>> пользователя - то, что и требовалось. Владельцами домашнего каталоге
>> по-прежнему будут me:me, т.е. wife не доберется до компромата!
> Вы так говорите, будто не видите проблем. Если потом раздать в локалку
> фотографии и дать права просмотра группе family, то случайно можно
> раздать совсем лишнюю информацию. Такое снижение безопасности очень
> неприятно.
Зачем давать права просмотра группе family? Та группа для МОДИФИКАЦИИ
данных, для просмотра подходят все остальные группы...


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 13:25 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>> Знаете, в сфере обсуждаемых здесь вопросов, владею в равной степени и
>> Linux и Windows.
> Хорошо, а как бы Вы решили данную задачу по виндовс?
> Там ведь те же проблемы с масками и умолчательными правами для каталогов.
> Проблема упирается в подходы предоставления прав доступа файлам, а не в
> различия их реализаций.
Нет там таких проблем. Во-первых, там в ACL есть права на изменения
прав и куча иных действий, а не только rwx. Далее ACL там наследуются,
это означает, что при копировании/перемещении файлов права
унаследованные от прежнего контейнера удаляются, а вписываются права
от нового контейнера, так что все файлы перенесенные в расшаренный
каталог автоматичеcки получат права от него. Кроме того права доступа
вписанные явно (а не унаследованные) сохраняются, таким образом можно
защитить данные от случайного копирования. Еще там используется три
состояния (разрешено/запрещено/не заданно), что дает большую гибкость
при раздачи прав.

Было бы здорово, если бы кто-нибудь реализовал для Linux файловую
систему с подобными ACL.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:

> Вы так говорите, будто не видите проблем. Если потом раздать в локалку
> фотографии и дать права просмотра группе family, то случайно можно
> раздать совсем лишнюю информацию. Такое снижение безопасности очень
> неприятно.
> 
Не вводите в группу family кого попало и будет приятно ;)

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 13:35 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>> Вы так говорите, будто не видите проблем. Если потом раздать в локалку
>> фотографии и дать права просмотра группе family, то случайно можно
>> раздать совсем лишнюю информацию. Такое снижение безопасности очень
>> неприятно.
>>
> Не вводите в группу family кого попало и будет приятно ;)
Так то оно так, но совет сродни "не ошибайтесь никогда и будет вам
счастье". Можно забыть в спешке и еще по какой причине. Сценариев
много. Любое руководство по безопасности UNIX пишет примерно
следующее:

"Настройте umask создания файлов для ваших пользователей настолько
ограничивающей насколько это возможно. Общеупотребительными являются
022, 033, и наиболее ограничивающая 077, и добавьте все это к
/etc/profile."

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

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Denis G. Samsonenko]

Привет!

14 января 2009 г. 16:29 Eugene Ostapets написал:
>> Вы так говорите, будто не видите проблем. Если потом раздать в локалку
>> фотографии и дать права просмотра группе family, то случайно можно
>> раздать совсем лишнюю информацию. Такое снижение безопасности очень
>> неприятно.
> Зачем давать права просмотра группе family? Та группа для МОДИФИКАЦИИ
> данных, для просмотра подходят все остальные группы...

А если не надо давать права на просмотр все остальным? Т.е. так:

1) группа, которая может читать, создавать, изменять и удалять файлы и
каталоги в указанном каталоге;
2) группа, которая может только читать;
3) все остальные, которые ничего не могут -- ни читать, ни писать.

Как это реализовать?

-- 
Всего доброго,

Денис.

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
>
> Да и разные главные группы для разных пользователей, это тоже
> требование безопасности. Так что менять эти вещи не стоит.
Опять вы какую-то странную траву покурили...
Это не требование безопасности для Unix - это исторический баг
красношляпых! Во всех Unix, которые мне попадались и в дистрибутивах
Linux, которые не имеют среди предков RedHat (например Debian или
Suse) пользователи заводятся в одной общей группе users!!!

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Denis G. Samsonenko <d.g.samsonenko gmail.com>:
> Привет!
>
> 14 января 2009 г. 16:29 Eugene Ostapets написал:
>>> Вы так говорите, будто не видите проблем. Если потом раздать в локалку
>>> фотографии и дать права просмотра группе family, то случайно можно
>>> раздать совсем лишнюю информацию. Такое снижение безопасности очень
>>> неприятно.
>> Зачем давать права просмотра группе family? Та группа для МОДИФИКАЦИИ
>> данных, для просмотра подходят все остальные группы...
>
> А если не надо давать права на просмотр все остальным? Т.е. так:
>
> 1) группа, которая может читать, создавать, изменять и удалять файлы и
> каталоги в указанном каталоге;
> 2) группа, которая может только читать;
> 3) все остальные, которые ничего не могут -- ни читать, ни писать.
>
> Как это реализовать?
Это БАЗОВЫЙ пример при рассмотрении прав в Unix!!! Неужели сами не догадались?
/exports/share1/photos
На share1 root:group1, права rwxr-x---
на photos root:group2, права rwxrwxr-x
Все, имеющие доступ к файлам в photos входят в группу group1, все
имеющие право изменять файлы в photos входят в группу group2. Файлы в
photos лежат с правами user:group2 rw-rw-r--, что достигается маской
002.
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Denis G. Samsonenko]

Привет!

14 января 2009 г. 16:49 Eugene Ostapets написал:
>>> Зачем давать права просмотра группе family? Та группа для МОДИФИКАЦИИ
>>> данных, для просмотра подходят все остальные группы...
>> А если не надо давать права на просмотр все остальным? Т.е. так:
>> 1) группа, которая может читать, создавать, изменять и удалять файлы и
>> каталоги в указанном каталоге;
>> 2) группа, которая может только читать;
>> 3) все остальные, которые ничего не могут -- ни читать, ни писать.
>>
>> Как это реализовать?
> Это БАЗОВЫЙ пример при рассмотрении прав в Unix!!! Неужели сами не догадались?
> /exports/share1/photos
> На share1 root:group1, права rwxr-x---
> на photos root:group2, права rwxrwxr-x
> Все, имеющие доступ к файлам в photos входят в группу group1, все
> имеющие право изменять файлы в photos входят в группу group2. Файлы в
> photos лежат с правами user:group2 rw-rw-r--, что достигается маской
> 002.

Т.е. приходится создавать дополнительный уровень вложенности
каталогов. А если усложнить: выделить группу которая может только
добавлять файлы, но не может изменять и удалять существующие?

-- 
Всего доброго,

Денис.

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Denis G. Samsonenko <d.g.samsonenko gmail.com>:
> Привет!
>>> Как это реализовать?
>> Это БАЗОВЫЙ пример при рассмотрении прав в Unix!!! Неужели сами не догадались?
>> /exports/share1/photos
>> На share1 root:group1, права rwxr-x---
>> на photos root:group2, права rwxrwxr-x
>> Все, имеющие доступ к файлам в photos входят в группу group1, все
>> имеющие право изменять файлы в photos входят в группу group2. Файлы в
>> photos лежат с правами user:group2 rw-rw-r--, что достигается маской
>> 002.
>
> Т.е. приходится создавать дополнительный уровень вложенности
> каталогов.
Так мы о чем, о правах и файлсервере или о бесконтрольной файлпомойке?
Для файлпомойки и других видов помоек всегда существовала Windows -
это ее ниша и туда никто не стремится.
> А если усложнить: выделить группу которая может только
> добавлять файлы, но не может изменять и удалять существующие?
Добавлять и удалять в идеологии unix одно и тоже право. Я не могу
сказать, хорошо это или плохо. Для решения задачи "только добавлять"
есть надежное средство - chattr +a dir

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Yury Aliaev пишет:
> Gennadii Redko пишет:
> 
>>
>>> Да, значит дело всё-таки не в моём незнании... Что ж, спасибо всем, 
>>> кто мне ответил, скажу сразу, что в моём случае геморрой не стоит 
>>> свеч и я поступлю проще, отдам весь каталог жене и если мне там 
>>> понадобится что-то поменять, буду под ней заходить.
>>
>> Да задача в самом деле простая.
>> Вас вводят в заблуждение.
>> Решается в рамках стандартных групповых политик назначением "s"-бита 
>> для группы в каталоге.
>> После установки этого бита файлы в этом каталоге создаются не с 
>> правами login group владельца файла, а с группой каталога.
>>
>> Я написал те две строчки, которые это делают, но Вы видимо их не 
>> заметили:
>>
>> Gennadii Redko пишет:
>> <skip>
>>  > #chown -R :photos /home/me/photos
>>  > #chmod g+s /home/me/photos
>>
> 
> Увы, не работает. Я так пытался (возможно, что не чётко сформулировал в 
> ответе). Получается следующее: подкаталоги создаются с владельцем либо 
> me, либо wife в зависимости от того, кто создавал, и с группой photos. 
> НО! Прав на записи для группы у подкаталогов по умолчанию нет. Т.е. при 
> создании каждого подкаталога нужно говорить "chmod g+w subdir" (или 
> аналогичное действие в каком-нибудь файловом менеджере). А хотелось как 
> раз обойтись без групповухи.
> 
>>
>>
>> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
> 
> Он как раз добавляется автоматически. Не добавляется бит записи для группы.
Сделайте umask 002 для профиля пользователя, как советует Евгений или к 
ярлычку konkuerora, открывающего папку с фотогорфиями добавьте строчку 
umask 002 и тогда файлы с записью для группы будут создаваться только в 
этом сеансе.
Вот строчка шелла демонстрирующая вышесказанное:
$ touch file;ls -l file; umask 002;touch file1;ls -l file1

Способов получить результат есть и немало...

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Gennadii Redko <uit1 zaz.zp.ua>:
> Yury Aliaev пишет:
>>> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
Кстати, только что проверил - sgid бит наследуется при создании
вложенных каталогов, как это и задумывалось авторами юникса...
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Denis G. Samsonenko]

Вечер добрый!

14 января 2009 г. 17:03 Eugene Ostapets написал:
>> Т.е. приходится создавать дополнительный уровень вложенности
>> каталогов.
> Так мы о чем, о правах и файлсервере или о бесконтрольной файлпомойке?
> Для файлпомойки и других видов помоек всегда существовала Windows -
> это ее ниша и туда никто не стремится.

Это всё лирика.

>> А если усложнить: выделить группу которая может только
>> добавлять файлы, но не может изменять и удалять существующие?
> Добавлять и удалять в идеологии unix одно и тоже право. Я не могу
> сказать, хорошо это или плохо. Для решения задачи "только добавлять"
> есть надежное средство - chattr +a dir

Что даже root не сможет в нём ничего удалить, пока не сделает chattr -a dir?

Всё это неудобно. По задаче каталог нужно один, и права доступа к нему
для разных групп нужны разные, для каждой свои.

Например, есть хранилище фильмов, есть группа которая может класть
туда фильмы, есть группа, которая может как класть, так и убирать,
есть группа, которая может только смотреть эти фильмы, а все остальные
не могут даже смотреть. При этом фильмы располагаются в общем каталоге
в согласии с некоторыми принципами, например по жанру или по режисёру
в соответствующих подкаталогах.

Получается, что просо сделать такое хранилище доступным для разных
групп пользователей с различными правами доступа к нему не получается,
приходится извращаться с вложенными каталогами и расстановкой прав на
них, да и то не всего этим методом можно достичь.

-- 
Всего доброго,

Денис.

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 14:15 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> 2009/1/14 Gennadii Redko <uit1 zaz.zp.ua>:
>> Yury Aliaev пишет:
>>>> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
> Кстати, только что проверил - sgid бит наследуется при создании
> вложенных каталогов, как это и задумывалось авторами юникса...
А при перемещении каталогов?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 14:19 пользователь Denis G. Samsonenko
<d.g.samsonenko@gmail.com> написал:
>> Так мы о чем, о правах и файлсервере или о бесконтрольной файлпомойке?
>> Для файлпомойки и других видов помоек всегда существовала Windows -
>> это ее ниша и туда никто не стремится.
> Это всё лирика.
>
> Всё это неудобно. По задаче каталог нужно один, и права доступа к нему
> для разных групп нужны разные, для каждой свои.
>
> Например, есть хранилище фильмов, есть группа которая может класть
> туда фильмы, есть группа, которая может как класть, так и убирать,
> есть группа, которая может только смотреть эти фильмы, а все остальные
> не могут даже смотреть. При этом фильмы располагаются в общем каталоге
> в согласии с некоторыми принципами, например по жанру или по режисёру
> в соответствующих подкаталогах.
>
> Получается, что просо сделать такое хранилище доступным для разных
> групп пользователей с различными правами доступа к нему не получается,
> приходится извращаться с вложенными каталогами и расстановкой прав на
> них, да и то не всего этим методом можно достичь.
Так и есть ( Я думаю, что можно дальше этого не обсуждать )

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Denis G. Samsonenko <d.g.samsonenko gmail.com>:
> Вечер добрый!
>>> А если усложнить: выделить группу которая может только
>>> добавлять файлы, но не может изменять и удалять существующие?
>> Добавлять и удалять в идеологии unix одно и тоже право. Я не могу
>> сказать, хорошо это или плохо. Для решения задачи "только добавлять"
>> есть надежное средство - chattr +a dir
>
> Что даже root не сможет в нём ничего удалить, пока не сделает chattr -a dir?
>
> Всё это неудобно. По задаче каталог нужно один, и права доступа к нему
> для разных групп нужны разные, для каждой свои.
>
> Например, есть хранилище фильмов, есть группа которая может класть
> туда фильмы, есть группа, которая может как класть, так и убирать,
> есть группа, которая может только смотреть эти фильмы, а все остальные
> не могут даже смотреть. При этом фильмы располагаются в общем каталоге
> в согласии с некоторыми принципами, например по жанру или по режисёру
> в соответствующих подкаталогах.
Читать про POSIX ACL до просветления, потому что все претензии к
юниксу безосновательны, такую файлпомойку можно элементарно
организовать. Лучше это делать на jfs, поскольку остальные файловые
системы заметно проседают на доступе к файлам после активизации posix
acl...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 14:15 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
>> 2009/1/14 Gennadii Redko <uit1 zaz.zp.ua>:
>>> Yury Aliaev пишет:
>>>>> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
>> Кстати, только что проверил - sgid бит наследуется при создании
>> вложенных каталогов, как это и задумывалось авторами юникса...
> А при перемещении каталогов?
А поробовать самому?


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> Так и есть ( Я думаю, что можно дальше этого не обсуждать )
Согласен, не вижу смысла обсуждать что-то с людьми некомпетентными и
отказывающимися хоть что-то прочитать из документации.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 14:26 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> 2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
>> 14 января 2009 г. 14:15 пользователь Eugene Ostapets
>> <eostapets@gmail.com> написал:
>>> 2009/1/14 Gennadii Redko <uit1 zaz.zp.ua>:
>>>> Yury Aliaev пишет:
>>>>>> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
>>> Кстати, только что проверил - sgid бит наследуется при создании
>>> вложенных каталогов, как это и задумывалось авторами юникса...
>> А при перемещении каталогов?
> А поробовать самому?
Это был риторический вопрос. Жаль что вы не поняли. В общем можете
попробовать, при перемещении все ваши хаки сломаются.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 14:26 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
>> 2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
>>> 14 января 2009 г. 14:15 пользователь Eugene Ostapets
>>> <eostapets@gmail.com> написал:
>>>> 2009/1/14 Gennadii Redko <uit1 zaz.zp.ua>:
>>>>> Yury Aliaev пишет:
>>>>>>> Правда нужно будет добавлять s-бит группам во всех вложенных каталогах...
>>>> Кстати, только что проверил - sgid бит наследуется при создании
>>>> вложенных каталогов, как это и задумывалось авторами юникса...
>>> А при перемещении каталогов?
>> А поробовать самому?
> Это был риторический вопрос. Жаль что вы не поняли. В общем можете
> попробовать, при перемещении все ваши хаки сломаются.
Прежде чем предложить вам попробовать, я попробовал сам... И знал
результат... А вы даже не попробовав сделали предположение о хаках и
их ломании... Извините, но мне лень тратить время на переписку с
воинствующим ламером, который знание получает не из опыта, а из
астрала...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 14:38 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
>>>> А при перемещении каталогов?
>>> А поробовать самому?
>> Это был риторический вопрос. Жаль что вы не поняли. В общем можете
>> попробовать, при перемещении все ваши хаки сломаются.
> Прежде чем предложить вам попробовать, я попробовал сам... И знал
> результат... А вы даже не попробовав сделали предположение о хаках и
> их ломании... Извините, но мне лень тратить время на переписку с
> воинствующим ламером, который знание получает не из опыта, а из
> астрала...
Ну что ж, давайте разжую. Я пробовал так делать. При перемещении s-bit
не применяется. Я тоже знал результат. Просто хотел, чтобы вы его тоже
узнали. Ну так знайте. Ну и ламером я вас не называл. Вы ведете себя
неподобающе.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 14:26 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> 2009/1/14 Denis G. Samsonenko <d.g.samsonenko gmail.com>:
>> Вечер добрый!
>>>> А если усложнить: выделить группу которая может только
>>>> добавлять файлы, но не может изменять и удалять существующие?
>>> Добавлять и удалять в идеологии unix одно и тоже право. Я не могу
>>> сказать, хорошо это или плохо. Для решения задачи "только добавлять"
>>> есть надежное средство - chattr +a dir
>>
>> Что даже root не сможет в нём ничего удалить, пока не сделает chattr -a dir?
>>
>> Всё это неудобно. По задаче каталог нужно один, и права доступа к нему
>> для разных групп нужны разные, для каждой свои.
>>
>> Например, есть хранилище фильмов, есть группа которая может класть
>> туда фильмы, есть группа, которая может как класть, так и убирать,
>> есть группа, которая может только смотреть эти фильмы, а все остальные
>> не могут даже смотреть. При этом фильмы располагаются в общем каталоге
>> в согласии с некоторыми принципами, например по жанру или по режисёру
>> в соответствующих подкаталогах.
> Читать про POSIX ACL до просветления, потому что все претензии к
> юниксу безосновательны, такую файлпомойку можно элементарно
> организовать. Лучше это делать на jfs, поскольку остальные файловые
> системы заметно проседают на доступе к файлам после активизации posix
> acl...
Извините, но читать до просветления вам. Такое можно сделать только
для сетевого доступа, при котором все файлы появляющиеся на шаре
являются вновь созданными. Только в этом случае срабатывает default
ACL, и не мешается маска. В случае локального доступа, когда файлы
могут перемещаться, или копироваться с read-only носителя, то ничего
не выйдет.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> 14 января 2009 г. 14:38 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
>>>>> А при перемещении каталогов?
>>>> А поробовать самому?
>>> Это был риторический вопрос. Жаль что вы не поняли. В общем можете
>>> попробовать, при перемещении все ваши хаки сломаются.
>> Прежде чем предложить вам попробовать, я попробовал сам... И знал
>> результат... А вы даже не попробовав сделали предположение о хаках и
>> их ломании... Извините, но мне лень тратить время на переписку с
>> воинствующим ламером, который знание получает не из опыта, а из
>> астрала...
> Ну что ж, давайте разжую. Я пробовал так делать. При перемещении s-bit
> не применяется.
Я еще раз вам пишу - ПРОВЕРЬТЕ. Я проверил - переместил каталог
принадлежащий user:root и sgid битом, бит СОХРАНИЛСЯ!
> Я тоже знал результат.
Вы его себе придумали, вы его никогда не знали!
> Просто хотел, чтобы вы его тоже узнали. Ну так знайте.
Еще раз, для тех, кто в танке... Перемещение каталога с sgid-битом не
сбрасывает этот бит!!! Сколько раз я должен вам это повторить, чтобы
вы перезагрузили компьютер из винды в линукс и таки ПРОВЕРИЛИ это!
> Ну и ламером я вас не называл. Вы ведете себя неподобающе.
Если после третьего предложения проверить на практике свои фантазии,
вы этого не сдалаете, то я вас назову иначе, но писать этого не буду,
поскольку почтовый фильтр на вас уже подготовлен, осталось подтвердить
диагноз и активировать фильтр.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 14:26 пользователь Eugene Ostapets
>>> Например, есть хранилище фильмов, есть группа которая может класть
>>> туда фильмы, есть группа, которая может как класть, так и убирать,
>>> есть группа, которая может только смотреть эти фильмы, а все остальные
>>> не могут даже смотреть. При этом фильмы располагаются в общем каталоге
>>> в согласии с некоторыми принципами, например по жанру или по режисёру
>>> в соответствующих подкаталогах.
>> Читать про POSIX ACL до просветления, потому что все претензии к
>> юниксу безосновательны, такую файлпомойку можно элементарно
>> организовать. Лучше это делать на jfs, поскольку остальные файловые
>> системы заметно проседают на доступе к файлам после активизации posix
>> acl...
> Извините, но читать до просветления вам. Такое можно сделать только
> для сетевого доступа, при котором все файлы появляющиеся на шаре
> являются вновь созданными.
Какого сетевого доступа? О чем вы?
> Только в этом случае срабатывает default ACL, и не мешается маска.
> В случае локального доступа, когда файлы могут перемещаться, или
> копироваться с read-only носителя, то ничего не выйдет.
У вас такая каша в голове, что я не могу понять без конкретики, ЧТО же
у вас не работает, потому что у меня работает все, что мне
требовалось. А read-only носитель решается только хаками в
пользовательской программе копирования, например в far, и к файловой
системе никакого отношения не имеет. Можете проверить это в вашем
любимом виндовсе. Там это так же больно...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Denis G. Samsonenko пишет:

> Например, есть хранилище фильмов, есть группа которая может класть
> туда фильмы, есть группа, которая может как класть, так и убирать,
> есть группа, которая может только смотреть эти фильмы, а все остальные
> не могут даже смотреть. При этом фильмы располагаются в общем каталоге
> в согласии с некоторыми принципами, например по жанру или по режисёру
> в соответствующих подкаталогах.
А что все эти люди работают на одном компьютере локально?
Или все же это некая сетевая задача?
Как бы размах не соответствует обсуждаемым средствам.
Ну не могут на рабочей станции работать десятки пользователей и групп.
Если доступ к файлам через сеть - есть Samba с ее списками групп и 
пользователей на чтение запись, с подменой групп, если хочется делать 
"как у любимых и неповторимых".

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 14:49 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
>> Ну что ж, давайте разжую. Я пробовал так делать. При перемещении s-bit
>> не применяется.
> Я еще раз вам пишу - ПРОВЕРЬТЕ. Я проверил - переместил каталог
> принадлежащий user:root и sgid битом, бит СОХРАНИЛСЯ!
$ mkdir test
$ mkdir test1
$ sudo chown :ftp test
$ sudo chmod g+s test
$ ls -ld test
drwxr-sr-x 2 rlz ftp 4096 Янв 14 14:54 test
$ mv test1 test
$ ls -l test
итого 4
drwxr-xr-x 2 rlz rlz 4096 Янв 14 14:54 test1
         ^            ^^^

Кто-то из нас не прав...

>> Я тоже знал результат.
> Вы его себе придумали, вы его никогда не знали!
>> Просто хотел, чтобы вы его тоже узнали. Ну так знайте.
> Еще раз, для тех, кто в танке... Перемещение каталога с sgid-битом не
> сбрасывает этот бит!!! Сколько раз я должен вам это повторить, чтобы
> вы перезагрузили компьютер из винды в линукс и таки ПРОВЕРИЛИ это!
>> Ну и ламером я вас не называл. Вы ведете себя неподобающе.
> Если после третьего предложения проверить на практике свои фантазии,
> вы этого не сдалаете, то я вас назову иначе, но писать этого не буду,
> поскольку почтовый фильтр на вас уже подготовлен, осталось подтвердить
> диагноз и активировать фильтр.
Ужас!!! Я так напуган...

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 14:57 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
> Ну не могут на рабочей станции работать десятки пользователей и групп.
Если эта станция в школьном классе то могут...

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 14:49 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
>>> Ну что ж, давайте разжую. Я пробовал так делать. При перемещении s-bit
>>> не применяется.
>> Я еще раз вам пишу - ПРОВЕРЬТЕ. Я проверил - переместил каталог
>> принадлежащий user:root и sgid битом, бит СОХРАНИЛСЯ!
> $ mkdir test
> $ mkdir test1
> $ sudo chown :ftp test
> $ sudo chmod g+s test
> $ ls -ld test
> drwxr-sr-x 2 rlz ftp 4096 Янв 14 14:54 test
> $ mv test1 test
> $ ls -l test
> итого 4
> drwxr-xr-x 2 rlz rlz 4096 Янв 14 14:54 test1
>         ^            ^^^
>
> Кто-то из нас не прав...
[eostapets@eostapets tmp]$ mkdir test1
[eostapets@eostapets tmp]$ mkdir test2
[eostapets@eostapets tmp]$ mkdir test1/move
[eostapets@eostapets tmp]$ chgrp _kvm test1/move/
[eostapets@eostapets tmp]$ chmod g+s test1/move/
[eostapets@eostapets tmp]$ mv test1/move/ test2/
[eostapets@eostapets tmp]$ ll test2/
итого 76
drwxr-xr-x  3 eostapets eostapets     8 Янв 14 14:03 ./
drwxr-sr-x  2 eostapets _kvm          1 Янв 14 14:03 move/
drwx------ 20 eostapets eostapets 65536 Янв 14 14:02 ../

Файловая система ext3, ядро 2.6.27-std-def-alt8


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:
>
> Ну что ж, давайте разжую. Я пробовал так делать. При перемещении s-bit
> не применяется. Я тоже знал результат. Просто хотел, чтобы вы его тоже
> узнали. Ну так знайте. Ну и ламером я вас не называл. Вы ведете себя
> неподобающе.
> 
Что ж - давайте конкретно, как "неламеры":
$ umask 022;mkdir ./example;ls -ld ./example; chmod g+ws ./example;ls 
-ld ./example;mkdir ./example/example1;ls -ld ./example/example1;mv 
./example/example1 ./;ls -ld ./example1;umask 002
drwxr-xr-x 2 henry henry 4096 Янв 14 14:06 ./example
drwxrwsr-x 2 henry henry 4096 Янв 14 14:06 ./example
drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example/example1
drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1


Что-то можете возразить?

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 15:03 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> 2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
>> 14 января 2009 г. 14:49 пользователь Eugene Ostapets
>> <eostapets@gmail.com> написал:
>>>> Ну что ж, давайте разжую. Я пробовал так делать. При перемещении s-bit
>>>> не применяется.
>>> Я еще раз вам пишу - ПРОВЕРЬТЕ. Я проверил - переместил каталог
>>> принадлежащий user:root и sgid битом, бит СОХРАНИЛСЯ!
>> $ mkdir test
>> $ mkdir test1
>> $ sudo chown :ftp test
>> $ sudo chmod g+s test
>> $ ls -ld test
>> drwxr-sr-x 2 rlz ftp 4096 Янв 14 14:54 test
>> $ mv test1 test
>> $ ls -l test
>> итого 4
>> drwxr-xr-x 2 rlz rlz 4096 Янв 14 14:54 test1
>>         ^            ^^^
>>
>> Кто-то из нас не прав...
> [eostapets@eostapets tmp]$ mkdir test1
> [eostapets@eostapets tmp]$ mkdir test2
> [eostapets@eostapets tmp]$ mkdir test1/move
> [eostapets@eostapets tmp]$ chgrp _kvm test1/move/
> [eostapets@eostapets tmp]$ chmod g+s test1/move/
> [eostapets@eostapets tmp]$ mv test1/move/ test2/
> [eostapets@eostapets tmp]$ ll test2/
> итого 76
> drwxr-xr-x  3 eostapets eostapets     8 Янв 14 14:03 ./
> drwxr-sr-x  2 eostapets _kvm          1 Янв 14 14:03 move/
> drwx------ 20 eostapets eostapets 65536 Янв 14 14:02 ../
>
> Файловая система ext3, ядро 2.6.27-std-def-alt8
Теперь понятно. Вы перемещаете папку, к которой есть общий доступ, в
другую, что не логично.

Я говорю, что не смотря на s-bit, если вы переместите другую папку в
расшаренную, то перемещаемая не получит ни группу, ни бит.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 15:08 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
> $ umask 022;mkdir ./example;ls -ld ./example; chmod g+ws ./example;ls -ld
> ./example;mkdir ./example/example1;ls -ld ./example/example1;mv
> ./example/example1 ./;ls -ld ./example1;umask 002
> drwxr-xr-x 2 henry henry 4096 Янв 14 14:06 ./example
> drwxrwsr-x 2 henry henry 4096 Янв 14 14:06 ./example
> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example/example1
> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1
>
>
> Что-то можете возразить?
Могу. Интереснее вместо mv ./example/example1 ./ сделать mv
/home/user/<somedir> ./example

В этом случае ./exsample/<somedir> не получит ни группы, ни бита и не
будет доступна членам группы доступа.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> Теперь понятно. Вы перемещаете папку, к которой есть общий доступ, в
> другую, что не логично.
Вы заявили, что sgid-бит обнуляется, я опроверг ваше утверждение.
>
> Я говорю, что не смотря на s-bit, если вы переместите другую папку в
> расшаренную, то перемещаемая не получит ни группу, ни бит.
Если перемещать папку в пределах одной файловой системы - да, если
перемещение происходит с другой файловой системы - и группа меняется и
бит выставляется... Кстати, тоже самое с default правами в acl...
Теперь я начинаю с трудом понимать что и когда у вас не работает, но
не понимаю почему вы не сделаете так, чтобы работало.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 15:08 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1
>> Что-то можете возразить?
> Могу. Интереснее вместо mv ./example/example1 ./ сделать mv
> /home/user/<somedir> ./example
>
> В этом случае ./exsample/<somedir> не получит ни группы, ни бита и не
> будет доступна членам группы доступа.
А я предложу вам сделать перемещение с другой файловой системы... И
все получится, и группа и бит...


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:
> 14 января 2009 г. 14:57 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>> Ну не могут на рабочей станции работать десятки пользователей и групп.
> Если эта станция в школьном классе то могут...
> 
И что в школьном классе фильмы хранят локально на ученических местах?

Я думаю, что если изменить постановку задачи, поставив перед собой цель 
не загнать в угол оппонента, а решить ее - решение найдется...

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:

> 
> Я говорю, что не смотря на s-bit, если вы переместите другую папку в
> расшаренную, то перемещаемая не получит ни группу, ни бит.
> 
А в винде по-другому?

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 15:17 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
>> Я говорю, что не смотря на s-bit, если вы переместите другую папку в
>> расшаренную, то перемещаемая не получит ни группу, ни бит.
> Если перемещать папку в пределах одной файловой системы - да, если
> перемещение происходит с другой файловой системы - и группа меняется и
> бит выставляется... Кстати, тоже самое с default правами в acl...
> Теперь я начинаю с трудом понимать что и когда у вас не работает, но
> не понимаю почему вы не сделаете так, чтобы работало.
А как сделать чтобы работало? Дело в том, что копирование, как и
перемещение с другого раздела приводят к созданию нового объекта ФС,
при этом применяются default acl и s-bit. А вот перемещение в рамках
раздела, это тот же объект, только, меняет родителя, к нему ничего
такого не применяется.

Это одна проблема. Вторая, это что при копировании с ro носителя права
владельца r-x, к вновь объекту они как правило применяются, что
приводит к сбрасыванию маски в ACL в r-x, и уже никто править такие
маски не может.

Ну и последняя проблема, что не все варианты можно уложить в rwx, надо больше.

Теперь вы меня поняли? Если сможете разрешить хотя бы две первые
проблемы буду очень благодарен.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 15:22 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
> Dmitriy M. Maslennikov пишет:
>> Я говорю, что не смотря на s-bit, если вы переместите другую папку в
>> расшаренную, то перемещаемая не получит ни группу, ни бит.
>>
> А в винде по-другому?
Там нет s-bit. Владелец просто всегда может редактировать права на
объект, а в остальном наравне с остальными пользователями.

Что же касается ACL, то записи делятся на заданные явно и
унаследованные. При всех файловых операциях заданные явно записи
остаются, старые унаследованные удаляются, а новые добавляются. По
умолчанию, файлы не имеют явных записей и права на них определяются
местом, в котором они лежат.

Права явно заданные для папки наследуются всем ее содержимым (я точно
не помню, но кажется это можно отменить и даже больше, можно задать
запись, которая к самой папке не применяется а вот к содержимому
будет).

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:

> Что же касается ACL, то записи делятся на заданные явно и
> унаследованные. При всех файловых операциях заданные явно записи
> остаются, старые унаследованные удаляются, а новые добавляются. По
> умолчанию, файлы не имеют явных записей и права на них определяются
> местом, в котором они лежат.
Что ж - другой подход со своими преимуществами, но и издержками.
Кстати не менее болезненными.
Нет например автоматизированной процедуры переноса "общих папок" между 
компьютерами.
То, что переносится с профилями - разруливается.
Тому, что лежит вне их - приходится менять права руками, т. к. не можем 
  подобрать непротиворечивой политики для наследования прав сетевых и 
локальных юзеров.
Их техподдержка предлагает вернуться к модели стандартных групповых 
политик...

Если файлы раздавать по самбе, то проблему s-бита в пределах одной шары 
можно решить опцией force directory mode

Re: [Comm] Каталог с совместным доступом

[Andriy Dobrovol`s`kii]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm@:
> 14 января 2009 г. 12:24 пользователь Dmitriy M. Maslennikov
> <maslennikovdm@gmail.com> написал:
>>> Как по мне, то можно поднять на локалке сайтец, который будет упорядочено
>>> показывать содержимое каталога и иметь функционал CRUD (create read update
>>> delete) и все.
>>> Остальное от лукавого...
>> И научить gcc компилировать программы, забирая их с сайта и заливая
>> туда результат, минуя ФС, ага, еще что предложите?
> Еще и каждого учителя обучаем писать сайты... Вместо того, чтобы
> просто настроить права доступа. Вы представляете насколько по
> трудозатратам отличается поднятие сайта от правки ACL в случае того же
> Windows? Да и по удобству работы ни в какое сравнение не идет, когда
> нужен не обмен файлами, не выкладывание, не документооборот, а именно
> работа с файлами.
Дмитрий, Вы начинаете "гнать пургу". Да в Окнах изначально все Ваши
даные  -- общедоступный мусор. В Альте, чтоб превратить свои даные в
такой мусор нужно выполнить некие действия. Это просто особенности
построения системы и ничего больше.
Если нужно научить детей работать с файлами -- нужно просто это и
сделать. А не прятать эту информацию за обертки. Лично меня совсем не
напрягает, что если я хочу сделать файл общедоступным, я должен
проследить за наличем у него соответствующих разрешений. Зато именно я
управляю доступом к своим файлам.
Если нужно учить программировать -- нужно показывать системы контроля
версий и учить принципам коллективной работы. А не воспитывать дурные
привычки бесконтрольного "барахтанья" в файлопомойке.
Вобщем стоит понять, что ОС не система организации рабочих процессо, а
основа для их построения. И сразу станет легче.
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> А как сделать чтобы работало? Дело в том, что копирование, как и
> перемещение с другого раздела приводят к созданию нового объекта ФС,
> при этом применяются default acl и s-bit. А вот перемещение в рамках
> раздела, это тот же объект, только, меняет родителя, к нему ничего
> такого не применяется.
Да, именно так это и задумывалось. Является ли это проблемой? Зависит
от задачи...
>
> Это одна проблема. Вторая, это что при копировании с ro носителя права
> владельца r-x, к вновь объекту они как правило применяются, что
> приводит к сбрасыванию маски в ACL в r-x, и уже никто править такие
> маски не может.
Это решается так же, как и в винде - в юзерском софте, которое
выполняет копирование. Я давно не видел винды, но точно помню что в
win2k копирование с cdrom можно было выполнять только с помощью фара,
в котором стояла галочка "снимать readonly при копировании с cdrom".
>
> Ну и последняя проблема, что не все варианты можно уложить в rwx, надо больше.
>
> Теперь вы меня поняли? Если сможете разрешить хотя бы две первые
> проблемы буду очень благодарен.
В плане расширения набора прав стоит посмотреть на nfs4acl for ext3,
но патч существует пока только для ядра 2.6.25 и из их описания я не
понял, занимались ли они проблемой move vs copy'n'delete, хотя в
дизайне nfs4acl этой проблемы нет.
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 15:57 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
> Dmitriy M. Maslennikov пишет:
> Что ж - другой подход со своими преимуществами, но и издержками.
> Кстати не менее болезненными.
> Нет например автоматизированной процедуры переноса "общих папок" между
> компьютерами.
Спасибо за вменяемый ответ. А не можете подробнее о "процедуре
переноса", а то меня вопрос разграничения доступа очень интересует, а
я таких проблем не встречал. А неизвестные проблемы гораздо хуже
известных )

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

> Если файлы раздавать по самбе, то проблему s-бита в пределах одной шары
> можно решить опцией force directory mode
А default acl?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 16:05 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> 2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
>> А как сделать чтобы работало? Дело в том, что копирование, как и
>> перемещение с другого раздела приводят к созданию нового объекта ФС,
>> при этом применяются default acl и s-bit. А вот перемещение в рамках
>> раздела, это тот же объект, только, меняет родителя, к нему ничего
>> такого не применяется.
> Да, именно так это и задумывалось. Является ли это проблемой? Зависит
> от задачи...
Наверное... А можете предложить правдоподобный случай показывающий
проблему в обратном случае?

>> Это одна проблема. Вторая, это что при копировании с ro носителя права
>> владельца r-x, к вновь объекту они как правило применяются, что
>> приводит к сбрасыванию маски в ACL в r-x, и уже никто править такие
>> маски не может.
> Это решается так же, как и в винде - в юзерском софте, которое
> выполняет копирование. Я давно не видел винды, но точно помню что в
> win2k копирование с cdrom можно было выполнять только с помощью фара,
> в котором стояла галочка "снимать readonly при копировании с cdrom".
Я тоже давно не видел, но не помню проблем при использовании другого
софта. Причем тот read-only не имеет отножения к правам доступа а
является атрибутом, еще оставшимся с 9x. Насколько помню, этот атрибут
является рекомендательным, проверяется софтом и уже давно никем не
используется, так что файлы что с ним, что без него можно
редактировать. Поправьте, если я не прав. Хорошо было бы, чтобы
кто-нибудь, у кого есть винда смог проверить это.

>> Теперь вы меня поняли? Если сможете разрешить хотя бы две первые
>> проблемы буду очень благодарен.
> В плане расширения набора прав стоит посмотреть на nfs4acl for ext3,
> но патч существует пока только для ядра 2.6.25 и из их описания я не
> понял, занимались ли они проблемой move vs copy'n'delete, хотя в
> дизайне nfs4acl этой проблемы нет.
Да, но это только для сети.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 16:05 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
>> 2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
>>> А как сделать чтобы работало? Дело в том, что копирование, как и
>>> перемещение с другого раздела приводят к созданию нового объекта ФС,
>>> при этом применяются default acl и s-bit. А вот перемещение в рамках
>>> раздела, это тот же объект, только, меняет родителя, к нему ничего
>>> такого не применяется.
>> Да, именно так это и задумывалось. Является ли это проблемой? Зависит
>> от задачи...
> Наверное... А можете предложить правдоподобный случай показывающий
> проблему в обратном случае?
Что такое "обратный случай"? А то мы в этом треде постоянно не так
понимаем друг друга...
>
>> Это решается так же, как и в винде - в юзерском софте, которое
>> выполняет копирование. Я давно не видел винды, но точно помню что в
>> win2k копирование с cdrom можно было выполнять только с помощью фара,
>> в котором стояла галочка "снимать readonly при копировании с cdrom".
> Я тоже давно не видел, но не помню проблем при использовании другого
> софта. Причем тот read-only не имеет отножения к правам доступа а
> является атрибутом, еще оставшимся с 9x. Насколько помню, этот атрибут
> является рекомендательным, проверяется софтом и уже давно никем не
> используется, так что файлы что с ним, что без него можно
> редактировать.
В том то и дело - нельзя было... Я долго обучал пользователей
правильному "копированию" компакт дисков :)
> Поправьте, если я не прав. Хорошо было бы, чтобы
> кто-нибудь, у кого есть винда смог проверить это.
С тех пор многое изменилось, может быть в ntfs5 старые атрибуты уже не
действуют...
>
>>> Теперь вы меня поняли? Если сможете разрешить хотя бы две первые
>>> проблемы буду очень благодарен.
>> В плане расширения набора прав стоит посмотреть на nfs4acl for ext3,
>> но патч существует пока только для ядра 2.6.25 и из их описания я не
>> понял, занимались ли они проблемой move vs copy'n'delete, хотя в
>> дизайне nfs4acl этой проблемы нет.
> Да, но это только для сети.
Вы не поняли, это не для сети - это расширение локальной файловой
системы, чтобы снять нагрузку с сетевых сервисов на трасляцию прав
CIFS/NFS4 "на лету" в права POSIX ACL. Т.е. это именно то, чего вы
хотите - расширение не количества объектов с правами, как делает POSIX
ACL, а само количество прав.


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 16:24 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
>>>> А как сделать чтобы работало? Дело в том, что копирование, как и
>>>> перемещение с другого раздела приводят к созданию нового объекта ФС,
>>>> при этом применяются default acl и s-bit. А вот перемещение в рамках
>>>> раздела, это тот же объект, только, меняет родителя, к нему ничего
>>>> такого не применяется.
>>> Да, именно так это и задумывалось. Является ли это проблемой? Зависит
>>> от задачи...
>> Наверное... А можете предложить правдоподобный случай показывающий
>> проблему в обратном случае?
> Что такое "обратный случай"? А то мы в этом треде постоянно не так
> понимаем друг друга...
Давайте считать обратной реализацию ACL в Windows.

> С тех пор многое изменилось, может быть в ntfs5 старые атрибуты уже не
> действуют...
В общем, я нашел удаленную винду с CD: атрибут работает, но проводник
при копировании его снимает. Видимо уже весь софт научился это делать,
так что проблема была снята хаком.

> Вы не поняли, это не для сети - это расширение локальной файловой
> системы, чтобы снять нагрузку с сетевых сервисов на трасляцию прав
> CIFS/NFS4 "на лету" в права POSIX ACL. Т.е. это именно то, чего вы
> хотите - расширение не количества объектов с правами, как делает POSIX
> ACL, а само количество прав.
Вот это да! Если я вас правильно понял, то вы для меня открыли
Америку. Обязательно посмотрю.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:
> 14 января 2009 г. 15:57 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>> Dmitriy M. Maslennikov пишет:
>> Что ж - другой подход со своими преимуществами, но и издержками.
>> Кстати не менее болезненными.
>> Нет например автоматизированной процедуры переноса "общих папок" между
>> компьютерами.
> Спасибо за вменяемый ответ. А не можете подробнее о "процедуре
> переноса", а то меня вопрос разграничения доступа очень интересует, а
> я таких проблем не встречал. А неизвестные проблемы гораздо хуже
> известных )
При  смене компьютера на новый приходится переносить данные.
При этом принадлежность данных группам и пользователям "слетает".
Как я понял из-за несоответствия идентификаторов на "старом" и "новом" 
компьютерах.
Я уж не знаю унаследованные они или умолчательные.
Но мне в общем-то по барабану эта специфика.
Должно работать как мне кажется правильным, как и наследование s-бита 
для каталогов в юниксах ;)
При этом пользователи и группы бывают как локальные так и доменные.
Часто бывает так, что на "новом" компьютере приходится заново задавать 
принадлежность файлов и каталогов.

> 

> Можете подробнее, а то я не понял, что за операция имеется ввиду.
Не могу, т. к. подробно не занимался.

> 
>> Если файлы раздавать по самбе, то проблему s-бита в пределах одной шары
>> можно решить опцией force directory mode
> А default acl?
Это тоже можно.
Речь ведь шла о каталогах?
Для обычных файлов s-бит для группы имеет другое значение.

> 

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 16:24 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
> Давайте считать обратной реализацию ACL в Windows.
Ха! :) Пример проблем тот же, что и с вложенными группами - выдав на
каталог очень верхнего уровня "наследуемые права" мы получаем их
непрозрачное перенесение на все подкаталоги. Т.е. без "проверить
эффективные права на объект" (или как это звучит в виндовсе), мы не
можем понять кто же на самом деле имеет права на файловый объект и
какие именно права. На этой "дырке" дизайна был украден не один
секретный файл.
>
>> С тех пор многое изменилось, может быть в ntfs5 старые атрибуты уже не
>> действуют...
> В общем, я нашел удаленную винду с CD: атрибут работает, но проводник
> при копировании его снимает. Видимо уже весь софт научился это делать,
> так что проблема была снята хаком.
Осталось только убедить разработчиков Линукса в необходимости
аналогичных хаков :)
>
>> Вы не поняли, это не для сети - это расширение локальной файловой
>> системы, чтобы снять нагрузку с сетевых сервисов на трасляцию прав
>> CIFS/NFS4 "на лету" в права POSIX ACL. Т.е. это именно то, чего вы
>> хотите - расширение не количества объектов с правами, как делает POSIX
>> ACL, а само количество прав.
> Вот это да! Если я вас правильно понял, то вы для меня открыли
> Америку. Обязательно посмотрю.
http://www.suse.de/~agruen/nfs4acl/
Только я уже говорил - оно не слишком свежее и пока что не так много
реализовано... А уж до официального ядра им еще как до Китая раком :)
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 16:41 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
> При  смене компьютера на новый приходится переносить данные.
> При этом принадлежность данных группам и пользователям "слетает".
> Как я понял из-за несоответствия идентификаторов на "старом" и "новом"
> компьютерах.
> Я уж не знаю унаследованные они или умолчательные.
> Но мне в общем-то по барабану эта специфика.
> Должно работать как мне кажется правильным, как и наследование s-бита для
> каталогов в юниксах ;)
> При этом пользователи и группы бывают как локальные так и доменные.
> Часто бывает так, что на "новом" компьютере приходится заново задавать
> принадлежность файлов и каталогов.
А все понял. Не вижу в этом проблемы. И она в Linux точно такая же
только даже чаще вылазиет и еще больше нежелательных эффектов имеет.

В Windows в качестве идентификатора пользователя используется
генерируемый "глобально-уникальный" SID, в Linux - 32-битный -UID.

Для новых пользователей всегда генерируется новый SID (и для групп).
Поэтому при переносе объектов с заданными явно ACL с машины на машину
приводит к тому, что прав на них ни у кого нет, так как SID'ы у
пользователей на другой машине другие. В Linux то же самое. Если UID'ы
не совпадут, то прав не будет, придется править. Только так как UID
часто совпадают, вы, возможно этого не замечали. Но если на старой
машине вы сначала создали пользователя Вася, а затем пользователя
Лена, а на другой в обратной последовательности, то при переносе они
обменяются файлами. Это порождает кучу других проблем. Так что здесь
тоже Windows ведет себя логичнее.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 16:44 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> Ха! :) Пример проблем тот же, что и с вложенными группами - выдав на
> каталог очень верхнего уровня "наследуемые права" мы получаем их
> непрозрачное перенесение на все подкаталоги. Т.е. без "проверить
> эффективные права на объект" (или как это звучит в виндовсе), мы не
> можем понять кто же на самом деле имеет права на файловый объект и
> какие именно права. На этой "дырке" дизайна был украден не один
> секретный файл.
Секретные файлы при создании надо помечать, что они ничего не
наследуют (так можно), и явно задавать разрешения.

>> В общем, я нашел удаленную винду с CD: атрибут работает, но проводник
>> при копировании его снимает. Видимо уже весь софт научился это делать,
>> так что проблема была снята хаком.
> Осталось только убедить разработчиков Линукса в необходимости
> аналогичных хаков :)
Думаю, что это из области фантастики.

>>> Вы не поняли, это не для сети - это расширение локальной файловой
>>> системы, чтобы снять нагрузку с сетевых сервисов на трасляцию прав
>>> CIFS/NFS4 "на лету" в права POSIX ACL. Т.е. это именно то, чего вы
>>> хотите - расширение не количества объектов с правами, как делает POSIX
>>> ACL, а само количество прав.
>> Вот это да! Если я вас правильно понял, то вы для меня открыли
>> Америку. Обязательно посмотрю.
> http://www.suse.de/~agruen/nfs4acl/
> Только я уже говорил - оно не слишком свежее и пока что не так много
> реализовано... А уж до официального ядра им еще как до Китая раком :)
Очень жаль. Значит все остается по-прежнему.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 16:44 пользователь Eugene Ostapets
> <eostapets gmail.com> написал:
>> Ха! :) Пример проблем тот же, что и с вложенными группами - выдав на
>> каталог очень верхнего уровня "наследуемые права" мы получаем их
>> непрозрачное перенесение на все подкаталоги. Т.е. без "проверить
>> эффективные права на объект" (или как это звучит в виндовсе), мы не
>> можем понять кто же на самом деле имеет права на файловый объект и
>> какие именно права. На этой "дырке" дизайна был украден не один
>> секретный файл.
> Секретные файлы при создании надо помечать, что они ничего не
> наследуют (так можно), и явно задавать разрешения.
Секретность его может быть не абсолютной, а относительной. А вот
невозможность легко контролировать права на файловый объект - это
большая дыра в всей архитектуре безопасности.
>
>>> В общем, я нашел удаленную винду с CD: атрибут работает, но проводник
>>> при копировании его снимает. Видимо уже весь софт научился это делать,
>>> так что проблема была снята хаком.
>> Осталось только убедить разработчиков Линукса в необходимости
>> аналогичных хаков :)
> Думаю, что это из области фантастики.
Скорее всего, но я думаю, что разработчики nautilus/konqueror могу
прислушаться к вашим словам, а это покроет нужды 99% пользователей,
которые не сообразят сразу же изменить права после копирования с
cdrom.
>
>>>> Вы не поняли, это не для сети - это расширение локальной файловой
>>>> системы, чтобы снять нагрузку с сетевых сервисов на трасляцию прав
>>>> CIFS/NFS4 "на лету" в права POSIX ACL. Т.е. это именно то, чего вы
>>>> хотите - расширение не количества объектов с правами, как делает POSIX
>>>> ACL, а само количество прав.
>>> Вот это да! Если я вас правильно понял, то вы для меня открыли
>>> Америку. Обязательно посмотрю.
>> http://www.suse.de/~agruen/nfs4acl/
>> Только я уже говорил - оно не слишком свежее и пока что не так много
>> реализовано... А уж до официального ядра им еще как до Китая раком :)
> Очень жаль. Значит все остается по-прежнему.
Слишком мал интерес к такой функциональности и у разработчиков, и у
пользователей. Гораздо проще продумать правила организации
файлохранилища и правила работы с ним, чтобы оно не превращалось в
файлопомойку. Тогда и имеющихся прав вполне хватает :)

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 16:41 пользователь Gennadii Redko <uit1 zaz.zp.ua> написал:
>> При  смене компьютера на новый приходится переносить данные.
>> При этом принадлежность данных группам и пользователям "слетает".
>> Как я понял из-за несоответствия идентификаторов на "старом" и "новом"
>> компьютерах.
>> Я уж не знаю унаследованные они или умолчательные.
>> Но мне в общем-то по барабану эта специфика.
>> Должно работать как мне кажется правильным, как и наследование s-бита для
>> каталогов в юниксах ;)
>> При этом пользователи и группы бывают как локальные так и доменные.
>> Часто бывает так, что на "новом" компьютере приходится заново задавать
>> принадлежность файлов и каталогов.
> А все понял. Не вижу в этом проблемы. И она в Linux точно такая же
> только даже чаще вылазиет и еще больше нежелательных эффектов имеет.
>
> В Windows в качестве идентификатора пользователя используется
> генерируемый "глобально-уникальный" SID, в Linux - 32-битный -UID.
>
> Для новых пользователей всегда генерируется новый SID (и для групп).
> Поэтому при переносе объектов с заданными явно ACL с машины на машину
> приводит к тому, что прав на них ни у кого нет, так как SID'ы у
> пользователей на другой машине другие. В Linux то же самое. Если UID'ы
> не совпадут, то прав не будет, придется править. Только так как UID
> часто совпадают, вы, возможно этого не замечали. Но если на старой
> машине вы сначала создали пользователя Вася, а затем пользователя
> Лена, а на другой в обратной последовательности, то при переносе они
> обменяются файлами. Это порождает кучу других проблем. Так что здесь
> тоже Windows ведет себя логичнее.
А вы не пробовали переносить с помощью tar или cpio? Вы будете
удивлены тем, что никакого обмена файлами не будет... И такое
поведению в юниксе мне кажется очень грамотным и логичным :)

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 17:05 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> А вы не пробовали переносить с помощью tar или cpio? Вы будете
> удивлены тем, что никакого обмена файлами не будет... И такое
> поведению в юниксе мне кажется очень грамотным и логичным :)
Я пробовал. Это и в Windows сработает. Я просто показал, что указанная
проблема общая, а не Windows-специфичная.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 17:05 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
>> А вы не пробовали переносить с помощью tar или cpio? Вы будете
>> удивлены тем, что никакого обмена файлами не будет... И такое
>> поведению в юниксе мне кажется очень грамотным и логичным :)
> Я пробовал. Это и в Windows сработает. Я просто показал, что указанная
> проблема общая, а не Windows-специфичная.
На самом деле решение проблемы старо как мир(т.е. было создано
компанией Microsoft еще во времена разработки OS/2):
getfacl -R C:\ > file
setfacl < file
Просто эти утилиты поставляются только с Windows Server, как и
множество других, незаменимых в хозяйстве :)
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 17:03 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> 2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> Секретность его может быть не абсолютной, а относительной. А вот
> невозможность легко контролировать права на файловый объект - это
> большая дыра в всей архитектуре безопасности.
Что вы подразумеваете под невозможностью контролировать права?
Эффективные права посмотреть можно, если вы об этом. И если вы даете
доступ к корню, то вы осознаете, что даете доступ ко многим объектам
сразу, так как это базовое свойство ACL в Windows. То есть вероятность
ошибочных действий очень мала.

> Скорее всего, но я думаю, что разработчики nautilus/konqueror могу
> прислушаться к вашим словам, а это покроет нужды 99% пользователей,
> которые не сообразят сразу же изменить права после копирования с
> cdrom.
Было бы здорово )

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

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Denis Nazarov]

On Wednesday 14 January 2009 15:35:06 Dmitriy M. Maslennikov wrote:
>  так что все файлы перенесенные в расшаренный
> каталог автоматичеcки получат права от него

ничего подобного. Как раз _перенесенные_ файлы тащут свои права с собой. А 
вот скопированные - да...

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 17:03 пользователь Eugene Ostapets
> <eostapets gmail.com> написал:
>> 2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
>> Секретность его может быть не абсолютной, а относительной. А вот
>> невозможность легко контролировать права на файловый объект - это
>> большая дыра в всей архитектуре безопасности.
> Что вы подразумеваете под невозможностью контролировать права?
> Эффективные права посмотреть можно, если вы об этом. И если вы даете
> доступ к корню, то вы осознаете, что даете доступ ко многим объектам
> сразу, так как это базовое свойство ACL в Windows. То есть вероятность
> ошибочных действий очень мала.
Практика показывает, что вероятность ошибочных действий приближается к
90% (это из опыта проведения аудита безопасности IT-инфраструктуры)
>
>> Скорее всего, но я думаю, что разработчики nautilus/konqueror могу
>> прислушаться к вашим словам, а это покроет нужды 99% пользователей,
>> которые не сообразят сразу же изменить права после копирования с
>> cdrom.
> Было бы здорово )
Пишите в их багзиллы. И попросите читателей этой рассылки
проголосовать за соответствующие баги:)
>
>> Слишком мал интерес к такой функциональности и у разработчиков, и у
>> пользователей. Гораздо проще продумать правила организации
>> файлохранилища и правила работы с ним, чтобы оно не превращалось в
>> файлопомойку. Тогда и имеющихся прав вполне хватает :)
> Ну не знаю. Иногда директору очень сложно объяснить, окуда взялись
> такие правила и почему он не может просто работать, как в винде, да
> еще и сотрудники должны учить какие-то правила.
Объясняется элементарно, когда задаешь вопрос типа "А сколько мы
потеряем, если файлы, составляющие тендерное предложение уйдут к
конкурентам?". После чего уже у тебя спрашивают как нужно обращаться с
файлами и файловой системой, чтобы такого не произошло.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 17:17 пользователь Denis Nazarov <marsden@mail.ru> написал:
> On Wednesday 14 January 2009 15:35:06 Dmitriy M. Maslennikov wrote:
>>  так что все файлы перенесенные в расшаренный
>> каталог автоматичеcки получат права от него
>
> ничего подобного. Как раз _перенесенные_ файлы тащут свои права с собой. А
> вот скопированные - да...
Вы про какую ОС?

Кроме того в Windows был баг, когда перенесенные действительно тащили
права с собой. Было в XP (по моему в SP2 еще тоже было, ну и до него).
Исправление от Microsoft тоже было.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 17:21 пользователь Eugene Ostapets
<eostapets@gmail.com> написал:
> Объясняется элементарно, когда задаешь вопрос типа "А сколько мы
> потеряем, если файлы, составляющие тендерное предложение уйдут к
> конкурентам?". После чего уже у тебя спрашивают как нужно обращаться с
> файлами и файловой системой, чтобы такого не произошло.
Хорошая мотивация, запомню.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
> 14 января 2009 г. 17:21 пользователь Eugene Ostapets
> <eostapets gmail.com> написал:
>> Объясняется элементарно, когда задаешь вопрос типа "А сколько мы
>> потеряем, если файлы, составляющие тендерное предложение уйдут к
>> конкурентам?". После чего уже у тебя спрашивают как нужно обращаться с
>> файлами и файловой системой, чтобы такого не произошло.
> Хорошая мотивация, запомню.
Знание психологии - наиболее сильное оружие в руках хорошего админа.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:
> 14 января 2009 г. 16:41 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>> При  смене компьютера на новый приходится переносить данные.
>> При этом принадлежность данных группам и пользователям "слетает".
>> Как я понял из-за несоответствия идентификаторов на "старом" и "новом"
>> компьютерах.
>> Я уж не знаю унаследованные они или умолчательные.
>> Но мне в общем-то по барабану эта специфика.
>> Должно работать как мне кажется правильным, как и наследование s-бита для
>> каталогов в юниксах ;)
>> При этом пользователи и группы бывают как локальные так и доменные.
>> Часто бывает так, что на "новом" компьютере приходится заново задавать
>> принадлежность файлов и каталогов.
> А все понял. Не вижу в этом проблемы. И она в Linux точно такая же
> только даже чаще вылазиет и еще больше нежелательных эффектов имеет.
В линуксе есть tar  c соответствующими опциями, так что нет особых
нежелательных эффектов.

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 17:27 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
> В линуксе есть tar  c соответствующими опциями, так что нет особых
> нежелательных эффектов.
В Windows тоже есть. Вся проблема один в один, только в Linux более
жестокая. Например, когда имеется переносной HDD диск не с vfat, то
файлы принадлежать на каждой системе разным пользователям, что в общем
случае нежелательно.

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

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Denis Nazarov]

On Wednesday 14 January 2009 19:22:53 Dmitriy M. Maslennikov wrote:
> Вы про какую ОС?
>
а вы разве не про винду?

> Кроме того в Windows был баг, когда перенесенные действительно тащили
> права с собой. Было в XP (по моему в SP2 еще тоже было, ну и до него).
> Исправление от Microsoft тоже было.

предпочитаю не тратить время на мониторинг, выкачку и установку исправлений 
от мелкомягких. А баг этот у них был не только в ХР, он был и есть до сих 
пор в 2003 сервер, только что проверил на относительно свежей установке 
Win2003 Std R2, купленной месяц назад. Методика - на диске имеется папка, 
имеющая особые разрешения, в эту папку _переместил_ другую, которая 
наследует разрешения и они, эти разрешения, отличаются от установленных в 
первой папке. После переноса вторая папка имеет свои собственные 
разрешения, отличные от особых разрешений первой папки. Так что баг 
остался.

А вообще, мне кажется, незачем сюда тащить виндовые приколы и глюки. 

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Eugene Ostapets пишет:
> 2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
>> 14 января 2009 г. 17:05 пользователь Eugene Ostapets
>> <eostapets@gmail.com> написал:
>>> А вы не пробовали переносить с помощью tar или cpio? Вы будете
>>> удивлены тем, что никакого обмена файлами не будет... И такое
>>> поведению в юниксе мне кажется очень грамотным и логичным :)
>> Я пробовал. Это и в Windows сработает. Я просто показал, что указанная
>> проблема общая, а не Windows-специфичная.
> На самом деле решение проблемы старо как мир(т.е. было создано
> компанией Microsoft еще во времена разработки OS/2):
> getfacl -R C:\ > file
> setfacl < file
> Просто эти утилиты поставляются только с Windows Server, как и
> множество других, незаменимых в хозяйстве :)
А оно и "сетевые" ID запоминает или только локальные?

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Dmitriy M. Maslennikov пишет:
> 14 января 2009 г. 17:27 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
>> В линуксе есть tar  c соответствующими опциями, так что нет особых
>> нежелательных эффектов.
> В Windows тоже есть. Вся проблема один в один, только в Linux более
> жестокая. Например, когда имеется переносной HDD диск не с vfat, то
> файлы принадлежать на каждой системе разным пользователям, что в общем
> случае нежелательно.
>
Я ношу с собой флешку с ext3 и каталогом, принажлежащим пользователю с 
одним именем и разными UID на разных компьютерах не сталкивался с 
подобными проблемами.
Вы наверное что-то специально делали, чтобы получить такой эффект?


> В виндовс же то, что я разрешил всем - всем и доступно, а мое доступно
> только мне и никому более.
> 

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Gennadii Redko <uit1 zaz.zp.ua>:
> Eugene Ostapets пишет:
>>
>> 2009/1/14 Dmitriy M. Maslennikov <maslennikovdm gmail.com>:
>> На самом деле решение проблемы старо как мир(т.е. было создано
>> компанией Microsoft еще во времена разработки OS/2):
>> getfacl -R C:\ > file
>> setfacl < file
>> Просто эти утилиты поставляются только с Windows Server, как и
>> множество других, незаменимых в хозяйстве :)
> А оно и "сетевые" ID запоминает или только локальные?
Как и в случае tar используется не ID(UID vs SID), а username.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

14 января 2009 г. 17:53 пользователь Gennadii Redko <uit1@zaz.zp.ua> написал:
> Я ношу с собой флешку с ext3 и каталогом, принажлежащим пользователю с одним
> именем и разными UID на разных компьютерах не сталкивался с подобными
> проблемами.
> Вы наверное что-то специально делали, чтобы получить такой эффект?
ext3 хранит только UID'ы, так что такую ситуацию очень сложно не
получить. Вы проверте, возможно, вы просто не обращали внимания на
проблему.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Yury Aliaev]

Gennadii Redko пишет:
> Dmitriy M. Maslennikov пишет:
>>
>> Ну что ж, давайте разжую. Я пробовал так делать. При перемещении s-bit
>> не применяется. Я тоже знал результат. Просто хотел, чтобы вы его тоже
>> узнали. Ну так знайте. Ну и ламером я вас не называл. Вы ведете себя
>> неподобающе.
>>
> Что ж - давайте конкретно, как "неламеры":
> $ umask 022;mkdir ./example;ls -ld ./example; chmod g+ws ./example;ls 
> -ld ./example;mkdir ./example/example1;ls -ld ./example/example1;mv 
> ./example/example1 ./;ls -ld ./example1;umask 002
> drwxr-xr-x 2 henry henry 4096 Янв 14 14:06 ./example
> drwxrwsr-x 2 henry henry 4096 Янв 14 14:06 ./example

> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example/example1

Ещё раз напоминаю: здесь мне нужны права drwxrwsr-s. Чувствуете разницу?

> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1
> 
> 
> Что-то можете возразить?

Re: [Comm] Каталог с совместным доступом

[Eugene Ostapets]

2009/1/14 Yury Aliaev <mutab0r rambler.ru>:
> Gennadii Redko пишет:
> Ещё раз напоминаю: здесь мне нужны права drwxrwsr-s. Чувствуете разницу?
>
>> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1
Сколько можно вам повторять про umask???

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Yury Aliaev пишет:

>> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example/example1
> 
> Ещё раз напоминаю: здесь мне нужны права drwxrwsr-s. Чувствуете разницу?
Так задайте то, что Вам нужно.
Нужен пример?

Re: [Comm] Каталог с совместным доступом

[Vitaly Lipatov]

On 14 января 2009, Andriy Dobrovol`s`kii wrote:
...
> Дмитрий, Вы начинаете "гнать пургу". Да в Окнах изначально все
> Ваши даные  -- общедоступный мусор. В Альте, чтоб превратить
> свои даные в такой мусор нужно выполнить некие действия. Это
Тем не менее, судя по бурному обсуждению практически 
единственного доступного решения (которое к тому же мало кому 
знакомо, а особенности его поведения выверяются только на 
практике), эти некие действия являются достаточно сложными.
На самом деле задача была простая - обеспечить двум пользователям 
взаимодействие с равными правами в одном каталоге. Это 
достигается установкой sgid-бита на каталоги, установкой общей 
группы на каталоги, и umask 0002, чтобы разрешить группе писать 
во вновь создаваемые файлы.
Это типичная ситуация (работа, как правило, происходит 
совместно), и единственное решение из доступных.

И никакого общедоступного мусора.

К сожалению, недостатки Unix/Linux слишком часто выдают за её 
достоинства. Вспомним
* Почивший сервер шрифтов XFS и вообще систему Иксовых шрифтов - 
как это красиво расписывалось и насколько бесполезно сейчас, 
когда используются только TTF-шрифты, отрисовываемые через 
freetype, и счастье, если отображаемые через XRender.
* Деление на пользователей, группы и других. В 2009 году до сих 
пор в ядре ограничение на 16 групп на пользователя при работе 
через NFS. Это означает что по сети группами пользоваться 
невозможно.
* Дефрагментация файловых систем. Сколько нам доказывалось, что 
это лишнее, и ФС в Linux не требует дефрагментации. Но только 
вот свежеустановленная система грузится заметно быстрее 
побывавшей в dist-upgrade. Что говорить, у меня на домашней 
машине установка rpm-пакета размером в 10Кб занимает несколько 
минут жуткого треска диска.
* Замечательная архитектура X-сервера с сетевым протоколом 
практически без оптимизации даже при локальной работе (я чего-то 
не знаю, кроме Unix socket?). Пользователи, перешедшие на Linux, 
порой проклинают нас за тормоза графического интерфейса.
* Несовместимость разных версий библиотек, драйверов для Иксов и 
модулей ядра даже на уровне исходного кода, не говоря уж об ABI, 
которого можно сказать и нет никогда. Иногда не грузятся 
драйвера ATI, иногда nVidia, коммерческую закрытую программу в 
дистрибутив не поставить, а модули ядра впрыгивают и выпрыгивают 
от сборки к сборке ядра в зависимости от готовности кода. Я уж 
молчу о счастье поддерживать сторонний модуль для ядра.
* Практически полное нежелание разработчиков разных дистрибутивов 
прийти хоть к какой-то совместимости и стандартизации 
программных интерфейсов в своих системах. Иногда этим занимаются 
сами разработчики библиотек и софта, но далёкими от нужд 
дистрибутивостроителей способами.

-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [Comm] Каталог с совместным доступом

[Alexey Novikov]

On Thu, Jan 15, 2009 at 02:11:25AM +0300, Vitaly Lipatov wrote:
> On 14 января 2009, Andriy Dobrovol`s`kii wrote:
> ...
> > Дмитрий, Вы начинаете "гнать пургу". Да в Окнах изначально все
> > Ваши даные  -- общедоступный мусор. В Альте, чтоб превратить
> > свои даные в такой мусор нужно выполнить некие действия. Это
> Тем не менее, судя по бурному обсуждению практически 
> единственного доступного решения (которое к тому же мало кому 
> знакомо, а особенности его поведения выверяются только на 
> практике), эти некие действия являются достаточно сложными.
> На самом деле задача была простая - обеспечить двум пользователям 
> взаимодействие с равными правами в одном каталоге. Это 
> достигается установкой sgid-бита на каталоги, установкой общей 
> группы на каталоги, и umask 0002, чтобы разрешить группе писать 
> во вновь создаваемые файлы.
> Это типичная ситуация (работа, как правило, происходит 
> совместно), и единственное решение из доступных.
> 
> И никакого общедоступного мусора.

Поразительно насколько разросся этот тред. Главное, что никто так
и не предложил автору сделать это самому: взять в руки напильник и
написать модуль для fuse реализующий данный функционал. Если
сложить время потраченное всеми участниками данной дискусси, то
модуль уже был бы готов. :(

-- 
WBR, Alexey Novikov
XMPP: alex-novikov@jabber.ru, shader@ya.ru

Re: [Comm] Каталог с совместным доступом

[Yury Aliaev]

Eugene Ostapets пишет:
> 2009/1/14 Yury Aliaev <mutab0r rambler.ru>:
>> Gennadii Redko пишет:
>> Ещё раз напоминаю: здесь мне нужны права drwxrwsr-s. Чувствуете разницу?
>>
>>> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1
> Сколько можно вам повторять про umask???
> 

Да слышал я. Только вот до сих пор не понял одну вещь: что и куда нужно 
выкрутить, чтобы только в каталоге photos на файлы и каталоги, ставились 
права drwxrwsr-x, а у остальных файлов, создаваемых тем же пользователем 
в других местах, право записи для группы не стояло бы?

Re: [Comm] Каталог с совместным доступом

[Yury Aliaev]

Gennadii Redko пишет:
> Yury Aliaev пишет:
> 
>>> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example/example1
>>
>> Ещё раз напоминаю: здесь мне нужны права drwxrwsr-s. Чувствуете разницу?
> Так задайте то, что Вам нужно.
> Нужен пример?
> 

Да, чтобы после mkdir examples/example1 безо всяких чмодов получил 
доступ по записи для группы

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

15 января 2009 г. 13:19 пользователь Yury Aliaev <mutab0r@rambler.ru> написал:
>> Сколько можно вам повторять про umask???
> Да слышал я. Только вот до сих пор не понял одну вещь: что и куда нужно
> выкрутить, чтобы только в каталоге photos на файлы и каталоги, ставились
> права drwxrwsr-x, а у остальных файлов, создаваемых тем же пользователем в
> других местах, право записи для группы не стояло бы?
Так вот я и говорю, что umask будет действовать для всех вновь
созданных файлов и директорий. А вот для перемещаемых вообще все, что
здесь говорили не стаботает, так как для них права и владельцы будут
сохраняться.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Dmitriy M. Maslennikov]

15 января 2009 г. 13:23 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
> 15 января 2009 г. 13:19 пользователь Yury Aliaev <mutab0r@rambler.ru> написал:
>>> Сколько можно вам повторять про umask???
>> Да слышал я. Только вот до сих пор не понял одну вещь: что и куда нужно
>> выкрутить, чтобы только в каталоге photos на файлы и каталоги, ставились
>> права drwxrwsr-x, а у остальных файлов, создаваемых тем же пользователем в
>> других местах, право записи для группы не стояло бы?
> Так вот я и говорю, что umask будет действовать для всех вновь
> созданных файлов и директорий. А вот для перемещаемых вообще все, что
> здесь говорили не стаботает, так как для них права и владельцы будут
> сохраняться.
"Всех" - имеется в виду вне зависимости от места создания.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] Каталог с совместным доступом

[Igor Vlasenko]

On Wed, Jan 14, 2009 at 12:25:03PM +0300, Yury Aliaev wrote:
> P.S. Для Игоря Власенко -- новый libquicktime сделаю как только  
> заработают механизмы, обеспечивающие выполнение условий из соглашения о  
> разделяемых библиотеках. Или они уже работают?

Чтобы они работали, надо немного переделать пакет,
а то он мною в свое время был не слишком красиво собран.
Вы просто тогда недостаточно распрямили его кривизну :)

Этот пакет для меня ностальгический: один из первых
пакетов, которые я выкладывал...

Тогда предлагаю так: когда будет время,
уберу из пакета оставшиеся грабли (версионирую plugindir), 
выложу правильный пакет в Сизиф и уже тогда 
попрошу вас присматривать.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [Comm] Каталог с совместным доступом

[Andriy Dobrovol`s`kii]

2009/1/15 Vitaly Lipatov <lav@altlinux.ru>:
> On 14 января 2009, Andriy Dobrovol`s`kii wrote:
> ...
>> Дмитрий, Вы начинаете "гнать пургу". Да в Окнах изначально все
>> Ваши даные  -- общедоступный мусор. В Альте, чтоб превратить
>> свои даные в такой мусор нужно выполнить некие действия. Это
> Тем не менее, судя по бурному обсуждению практически
> единственного доступного решения (которое к тому же мало кому
> знакомо, а особенности его поведения выверяются только на
> практике), эти некие действия являются достаточно сложными.
Я не спорю с тем сложно или нет решение.
> На самом деле задача была простая - обеспечить двум пользователям
> взаимодействие с равными правами в одном каталоге. Это
> достигается установкой sgid-бита на каталоги, установкой общей
> группы на каталоги, и umask 0002, чтобы разрешить группе писать
> во вновь создаваемые файлы.
Как уже было отмечено, равный доступ в каталог для группы открыть не
сложно. Дальнейшее сотрудничество "осложняется" только необходимостью
вовремя предоставлять доступ к нужным файлам остальным. И всё. Лично я
тут сложности не вижу. Только лень.
> Это типичная ситуация (работа, как правило, происходит
> совместно), и единственное решение из доступных.
>
> И никакого общедоступного мусора.
>
> К сожалению, недостатки Unix/Linux слишком часто выдают за её
> достоинства. Вспомним
(порезано)
> * Дефрагментация файловых систем. Сколько нам доказывалось, что
> это лишнее, и ФС в Linux не требует дефрагментации. Но только
> вот свежеустановленная система грузится заметно быстрее
> побывавшей в dist-upgrade. Что говорить, у меня на домашней
> машине установка rpm-пакета размером в 10Кб занимает несколько
> минут жуткого треска диска.
Странно. У меня тоже система многократно дистапгрейдилась и нет
такого. Может стоит проверить состояние диска? (Это я безотносительно
к дефрагментации.)
(порезано)
Не хочу с этим спорить. Самого раздражает... :)
Просто я не понимаю почему нежелание обучить пользователя элементарным
операциям преподносится как проблема системы?
В крайнем случае, можно составить непротиворечивое т.з. и реализовать
его на практике. Если оно и правда нужно. Как надстройку над
системными функциями.
Не нужно забывать и то, что в Окнах одна фс а в Юниксах десяток. Т.е.
такая функциональность и не должна реализовываться на уровне файловых
систем.
Хотя и может.
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Vitaly Lipatov пишет:

> это лишнее, и ФС в Linux не требует дефрагментации. Но только 
> вот свежеустановленная система грузится заметно быстрее 
> побывавшей в dist-upgrade. Что говорить, у меня на домашней 
> машине установка rpm-пакета размером в 10Кб занимает несколько 
> минут жуткого треска диска.
Фрагментация на заполненном диске конечно есть и в линуксе.
Спорна только эффективность программ-дефрагментаторов.
Давно хотелось увидеть количественный результат падения 
производительности диска в линуксе от дефрагментации.
Только не было диска подходящего.
Может Вы попробуете оценить раз появилась возможность?
Нужно:
1. Заготовить параметры запуска bonnie++
2. Прогнать тест на фрагментированном диске
3. Сохранить результат
4. Сделать файловый бэкап содержимого всего диска (tar|cp ax ???)
5. Сделать mkfs исходному диску
6. Вернуть файлы назад и восстановить загрузчик, если диск загрузочный
7. Прогнать тест на дефрагментированном диске.
8. Сравнить результаты.

Я понимаю, что это Ваше время, но дефрагментатор его тоже занимает, а Вы 
же хотите повышения производительности диска :)

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

Yury Aliaev пишет:
> Eugene Ostapets пишет:
>> 2009/1/14 Yury Aliaev <mutab0r rambler.ru>:
>>> Gennadii Redko пишет:
>>> Ещё раз напоминаю: здесь мне нужны права drwxrwsr-s. Чувствуете разницу?
>>>
>>>> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1
>> Сколько можно вам повторять про umask???
>>
> 
> Да слышал я. Только вот до сих пор не понял одну вещь: что и куда нужно 
> выкрутить, чтобы только в каталоге photos на файлы и каталоги, ставились 
> права drwxrwsr-x, а у остальных файлов, создаваемых тем же пользователем 
> в других местах, право записи для группы не стояло бы?
Команда umask меняет маску создания файлов для сеанса, а не для каталога.
Но можно ярлычок на рабочий стол вынести.
Например как во вложении.
Понятно, что ничто не мешает подняться выше заданного каталога, но 
работать можно пока ничего другого не придумано :)

[-- Attachment #2: Фотографии.desktop --]
[-- Type: application/x-desktop, Size: 352 bytes --]

Re: [Comm] Каталог с совместным доступом

[Алексей Синицын]

15 января 2009 г. 18:27 пользователь Gennadii Redko <...> написал:

>> свежеустановленная система грузится заметно быстрее побывавшей в
>> dist-upgrade. Что говорить, у меня на домашней машине установка rpm-пакета
>> размером в 10Кб занимает несколько минут жуткого треска диска.
>
> Фрагментация на заполненном диске конечно есть и в линуксе.
> Спорна только эффективность программ-дефрагментаторов.
> Давно хотелось увидеть количественный результат падения производительности
> диска в линуксе от дефрагментации.
> Только не было диска подходящего.
> Может Вы попробуете оценить раз появилась возможность?
> Нужно:
> 1. Заготовить параметры запуска bonnie++
> 2. Прогнать тест на фрагментированном диске
> 3. Сохранить результат
> 4. Сделать файловый бэкап содержимого всего диска (tar|cp ax ???)
> 5. Сделать mkfs исходному диску
> 6. Вернуть файлы назад и восстановить загрузчик, если диск загрузочный
> 7. Прогнать тест на дефрагментированном диске.
> 8. Сравнить результаты.
>

 Думаю результат должен зависеть от разметки диска.

 Один общий раздел или разнесены:

/
/var
/home
/tmp
/storage

 Конечно, один раздел удобнее, но сильно подозреваю что чем мельче
разбито (/boot, /usr, ...) и чем больше на каждом (кроме помойки)
свободного места, тем лучше картина.

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Алексей Синицын пишет:
> 15 января 2009 г. 18:27 пользователь Gennadii Redko <...> написал:
> 
>>> свежеустановленная система грузится заметно быстрее побывавшей в
>>> dist-upgrade. Что говорить, у меня на домашней машине установка rpm-пакета
>>> размером в 10Кб занимает несколько минут жуткого треска диска.
>> Фрагментация на заполненном диске конечно есть и в линуксе.
>> Спорна только эффективность программ-дефрагментаторов.
>> Давно хотелось увидеть количественный результат падения производительности
>> диска в линуксе от дефрагментации.
>> Только не было диска подходящего.
>> Может Вы попробуете оценить раз появилась возможность?
>> Нужно:
>> 1. Заготовить параметры запуска bonnie++
>> 2. Прогнать тест на фрагментированном диске
>> 3. Сохранить результат
>> 4. Сделать файловый бэкап содержимого всего диска (tar|cp ax ???)
>> 5. Сделать mkfs исходному диску
>> 6. Вернуть файлы назад и восстановить загрузчик, если диск загрузочный
>> 7. Прогнать тест на дефрагментированном диске.
>> 8. Сравнить результаты.
>>
> 
>  Думаю результат должен зависеть от разметки диска.
> 
>  Один общий раздел или разнесены:
> 
> /
> /var
> /home
> /tmp
> /storage
> 
>  Конечно, один раздел удобнее, но сильно подозреваю что чем мельче
> разбито (/boot, /usr, ...) и чем больше на каждом (кроме помойки)
> свободного места, тем лучше картина.
Предположений много, но кто показал численно, что дефрагментация влияет 
на дисковую производительность?
Надо бы экперимент показывающий как наличие такого эффекта, так и 
степень влияния дефрагментации на производительность.

А предположений можно много высказывать, но это будет литературный 
конкурс...

Re: [Comm] Каталог с совместным доступом

[Денис Назаров]

> Фрагментация на заполненном диске конечно есть и в линуксе.
> Спорна только эффективность программ-дефрагментаторов.

а есть возможность как-то оценить фрагментированность диска? У меня на ноуте
домашка забита почти полностью (170 Гб), тормозит страшно, собираюсь 
на следующей неделе сделать нечто подобное, но хотелось бы узнать, насколько
сейчас все фрагментировано 

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Денис Назаров пишет:
>> Фрагментация на заполненном диске конечно есть и в линуксе.
>> Спорна только эффективность программ-дефрагментаторов.
> 
> а есть возможность как-то оценить фрагментированность диска? У меня на ноуте
> домашка забита почти полностью (170 Гб), тормозит страшно, собираюсь 
> на следующей неделе сделать нечто подобное, но хотелось бы узнать, насколько
> сейчас все фрагментировано 
> 
Так я же написал последовательность.
Что касается параметров bonnie++, то как написано вот в этой статье:
http://www.linux.com/feature/139742
Достаточно запустить:
bonnie++ -d /tmp/foo
Вроде бы умолчательные параметры корректны.

Re: [Comm] Каталог с совместным доступом

[Yury Aliaev]

Gennadii Redko пишет:

>>>> Ещё раз напоминаю: здесь мне нужны права drwxrwsr-s. Чувствуете 
>>>> разницу?
>>>>
>>>>> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1
>>> Сколько можно вам повторять про umask???
>>>
>>
>> Да слышал я. Только вот до сих пор не понял одну вещь: что и куда 
>> нужно выкрутить, чтобы только в каталоге photos на файлы и каталоги, 
>> ставились права drwxrwsr-x, а у остальных файлов, создаваемых тем же 
>> пользователем в других местах, право записи для группы не стояло бы?
> Команда umask меняет маску создания файлов для сеанса, а не для каталога.

Эх костыли, костыли... В общем я понял, что простыми средствами эту 
проблему не решить, так что интерес к этой теме теряю.

> Но можно ярлычок на рабочий стол вынести.
> Например как во вложении.

И mc тоже предлагаете руками патчить?..

> Понятно, что ничто не мешает подняться выше заданного каталога, но 
> работать можно пока ничего другого не придумано :)

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Yury Aliaev пишет:
> Gennadii Redko пишет:
> 
>>>>> Ещё раз напоминаю: здесь мне нужны права drwxrwsr-s. Чувствуете 
>>>>> разницу?
>>>>>
>>>>>> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1
>>>> Сколько можно вам повторять про umask???
>>>>
>>>
>>> Да слышал я. Только вот до сих пор не понял одну вещь: что и куда 
>>> нужно выкрутить, чтобы только в каталоге photos на файлы и каталоги, 
>>> ставились права drwxrwsr-x, а у остальных файлов, создаваемых тем же 
>>> пользователем в других местах, право записи для группы не стояло бы?
>> Команда umask меняет маску создания файлов для сеанса, а не для каталога.
> 
> Эх костыли, костыли... В общем я понял, что простыми средствами эту 
> проблему не решить, так что интерес к этой теме теряю.
> 
Так Вы хотите свою проблему решить или побороться за права "простых 
пользователей"?
Вы бы сразу сказали, что речь о правах обиженных юзеров - я бы не 
напрягался :(
>> Но можно ярлычок на рабочий стол вынести.
>> Например как во вложении.
> 
> И mc тоже предлагаете руками патчить?..
В смысле - сделать еще и ярлычок для вызова mc с umask 002?

> 
>> Понятно, что ничто не мешает подняться выше заданного каталога, но 
>> работать можно пока ничего другого не придумано :)
> 

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

[-- Attachment #1: Type: text/plain, Size: 107 bytes --]

Yury Aliaev пишет:

> И mc тоже предлагаете руками патчить?..
Просто скопируйте ярлычок на рабочий стол ;)

[-- Attachment #2: Фото в MC.desktop --]
[-- Type: application/x-desktop, Size: 355 bytes --]

Re: [Comm] Каталог с совместным доступом

[Yury Aliaev]

Igor Vlasenko пишет:

>> P.S. Для Игоря Власенко -- новый libquicktime сделаю как только  
>> заработают механизмы, обеспечивающие выполнение условий из соглашения о  
>> разделяемых библиотеках. Или они уже работают?
> 
> Чтобы они работали, надо немного переделать пакет,
> а то он мною в свое время был не слишком красиво собран.
> Вы просто тогда недостаточно распрямили его кривизну :)
> 
> Этот пакет для меня ностальгический: один из первых
> пакетов, которые я выкладывал...
> 
> Тогда предлагаю так: когда будет время,
> уберу из пакета оставшиеся грабли (версионирую plugindir), 
> выложу правильный пакет в Сизиф и уже тогда 
> попрошу вас присматривать.
> 

Хорошо, на таких условиях я согласен :) А как быть с автоматическим 
удалением старой версии пакета, когда от неё перестаёт что-либо 
зависеть? Это уже работает?

Re: [Comm] Каталог с совместным доступом

[Yury Aliaev]

Gennadii Redko пишет:
>>
>>>>>> Ещё раз напоминаю: здесь мне нужны права drwxrwsr-s. Чувствуете 
>>>>>> разницу?
>>>>>>
>>>>>>> drwxr-sr-x 2 henry henry 4096 Янв 14 14:06 ./example1
>>>>> Сколько можно вам повторять про umask???
>>>>>
>>>>
>>>> Да слышал я. Только вот до сих пор не понял одну вещь: что и куда 
>>>> нужно выкрутить, чтобы только в каталоге photos на файлы и каталоги, 
>>>> ставились права drwxrwsr-x, а у остальных файлов, создаваемых тем же 
>>>> пользователем в других местах, право записи для группы не стояло бы?
>>> Команда umask меняет маску создания файлов для сеанса, а не для 
>>> каталога.
>>
>> Эх костыли, костыли... В общем я понял, что простыми средствами эту 
>> проблему не решить, так что интерес к этой теме теряю.
>>
> Так Вы хотите свою проблему решить или побороться за права "простых 
> пользователей"?
> Вы бы сразу сказали, что речь о правах обиженных юзеров - я бы не 
> напрягался :(

Нет, меня по дороге заинтересовала возможность точного решения 
поставленной задачи (с наследованием прав доступа от родительского 
каталога). Но это не обязательно, так для общей эрудиции. Вариант с 
umask для домашней машины в принципе устраивает, после некоторого 
раздумья я понял, что так в результате и сделаю. Ещё раз спасибо всем за 
советы и обсуждение :)

>>> Но можно ярлычок на рабочий стол вынести.
>>> Например как во вложении.
>>
>> И mc тоже предлагаете руками патчить?..
> В смысле - сделать еще и ярлычок для вызова mc с umask 002?

В консоли?

Re: [Comm] Каталог с совместным доступом

[Gennadii Redko]

Yury Aliaev пишет:

>> В смысле - сделать еще и ярлычок для вызова mc с umask 002?
> 
> В консоли?
А Вы смотрите фотографии из консоли?
Есть конечно и там способы задать маску на время сеанса, но может Вы 
поправите профиль на предмет umask?
Последствия этого шага не так уж страшны.
Ну можно будет Ваши файлы по умолчанию редактировать еще и членам Вашей 
логингруп...

Re: [Comm] Каталог с совместным доступом

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

Dmitriy M. Maslennikov пишет:
> 14 января 2009 г. 15:17 пользователь Eugene Ostapets
> <eostapets@gmail.com> написал:
>>> Я говорю, что не смотря на s-bit, если вы переместите другую папку в
>>> расшаренную, то перемещаемая не получит ни группу, ни бит.
>> Если перемещать папку в пределах одной файловой системы - да, если
>> перемещение происходит с другой файловой системы - и группа меняется и
>> бит выставляется... Кстати, тоже самое с default правами в acl...
>> Теперь я начинаю с трудом понимать что и когда у вас не работает, но
>> не понимаю почему вы не сделаете так, чтобы работало.
> А как сделать чтобы работало? Дело в том, что копирование, как и
> перемещение с другого раздела приводят к созданию нового объекта ФС,
> при этом применяются default acl и s-bit. А вот перемещение в рамках
> раздела, это тот же объект, только, меняет родителя, к нему ничего
> такого не применяется.

   А что мешает вытащить шару на отдельный раздел?

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [Comm] Каталог с совместным доступом

[Yury Aliaev]

Gennadii Redko пишет:
> Yury Aliaev пишет:
> 
>>> В смысле - сделать еще и ярлычок для вызова mc с umask 002?
>>
>> В консоли?
> А Вы смотрите фотографии из консоли?

Я их часто с фотоппарата копирую в консоли.

> Есть конечно и там способы задать маску на время сеанса, но может Вы 
> поправите профиль на предмет umask?
> Последствия этого шага не так уж страшны.
> Ну можно будет Ваши файлы по умолчанию редактировать еще и членам Вашей 
> логингруп...

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

Re: [Comm] Каталог с совместным доступом

[Алексей Синицын]

16 января 2009 г. 10:01 пользователь Gennadii Redko <...> написал:

>>> Фрагментация на заполненном диске конечно есть и в линуксе.
>>> Спорна только эффективность программ-дефрагментаторов.
>>> Давно хотелось увидеть количественный результат падения
>>> производительности
>>> диска в линуксе от дефрагментации.
>>> Только не было диска подходящего.
>>> Может Вы попробуете оценить раз появилась возможность?
>>> Нужно:
>>> 1. Заготовить параметры запуска bonnie++
>>> 2. Прогнать тест на фрагментированном диске
>>> 3. Сохранить результат
>>> 4. Сделать файловый бэкап содержимого всего диска (tar|cp ax ???)
>>> 5. Сделать mkfs исходному диску
>>> 6. Вернуть файлы назад и восстановить загрузчик, если диск загрузочный
>>> 7. Прогнать тест на дефрагментированном диске.
>>> 8. Сравнить результаты.
>>>
>>
>>  Думаю результат должен зависеть от разметки диска.
>>
>>  Один общий раздел или разнесены:
>>
>> /
>> /var
>> /home
>> /tmp
>> /storage
>>
>>  Конечно, один раздел удобнее, но сильно подозреваю что чем мельче
>> разбито (/boot, /usr, ...) и чем больше на каждом (кроме помойки)
>> свободного места, тем лучше картина.
>
> Предположений много, но кто показал численно, что дефрагментация влияет на
> дисковую производительность?
> Надо бы экперимент показывающий как наличие такого эффекта, так и степень
> влияния дефрагментации на производительность.
>

 На моей памяти есть по крайней мере одно сравнение:
 http://www.linux.org.ru/view-message.jsp?msgid=2641133

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

Re: [Comm] Каталог с совместным доступом

[Алексей Синицын]

17 января 2009 г. 16:51 пользователь Алексей Синицын
<asinitsinster@gmail.com> написал:

>> Предположений много, но кто показал численно, что дефрагментация влияет на
>> дисковую производительность?
>> Надо бы экперимент показывающий как наличие такого эффекта, так и степень
>> влияния дефрагментации на производительность.
>>
>
>  На моей памяти есть по крайней мере одно сравнение:
>  http://www.linux.org.ru/view-message.jsp?msgid=2641133
>
>  Вообще, этот товарищ заметно интересовался вопросами дефрагментации и
> даже проводил какие-то тесты файловых систем с графиками и выводами
> включая и эти вопросы, но я что-то нашёл только это. У него есть свой
> форум и можно наверно попробовать обратиться к нему или там-же, или на
> его форуме.
>

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

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

 Синтетический тест на увеличение фрагментации можно сделать легко:
пишем на диск файлы размером мегабайт до заполнения, удаляем через
один - заполняем появившееся место файлами в полтора. И так -
несколько раз, увеличивая размер файла. Затем тестируем файловые
операции. Вопрос в том, что происходит в реальности. Например при
обновлении системы но при наличии свободного места на диске и
достаточной оперативной памяти для кэшей. При выделении помойки на
отдельный раздел и вообще нарезке системы. При увеличении фрагментации
на отдельных компонентах (/, /var, /home, /storage, ...).

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

Re: [Comm] Каталог с совместным доступом

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Fri, Jan 16, 2009 at 10:06:49AM +0300, Денис Назаров wrote:
> 
> > Фрагментация на заполненном диске конечно есть и в линуксе.
> > Спорна только эффективность программ-дефрагментаторов.
> 
> а есть возможность как-то оценить фрагментированность диска? У меня на ноуте
> домашка забита почти полностью (170 Гб), тормозит страшно, собираюсь 
> на следующей неделе сделать нечто подобное, но хотелось бы узнать, насколько
> сейчас все фрагментировано 

Для ext2/3 процент фрагментированных файлов выводится при выполнении
fsck, но количество фрагментов, на которые оказался разбит файл, при
этом не учитывается.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]