есть ли решение проблемы наследования acl mask при создании/копировании файлов через NFS

[Владимир Скубриев]

Добрый день!

Есть сервер NFS и расшареный каталог.

В нем есть папка common которой установлены расширенные acl по умолчанию

setfacl -m d:g:__USERS__:rwx common/

и установлена маска по умолчанию:

setfacl -m d:m:rwx common/

Если зайти на сервер NFS локально и создать там файл и папку локально

user@comp:/storage/shares/common# getfacl dir-local-created/
# file: dir-local-created/
# owner: root
# group: __USERS__
# flags: -s-
user::rwx
group::rwx
group:__USERS__:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:__USERS__:rwx
default:mask::rwx
default:other::r-x

С папкой проблем нет: default:mask::rwx

user@comp:/storage/shares/common# getfacl file-local-created
# file: file-local-created
# owner: root
# group: __USERS__
user::rw-
group::rwx #effective:rw-
group:__USERS__:rwx #effective:rw-
mask::rw-
other::r--

С Файлом есть проблема: mask::rw-

Маска поменялась. Я так понимаю в этом случае она все равно
пересчитывается исходя из текущего (umask) и системного
(/etc/login.defs) значений масок. Я прав ?

Как быть ? Если хочется чтобы наследование работало исключительно в
зависимости от того, какие разрешения заданы родительскому объекту ?

А вот с NFS несколько другая история.


user@comp:/storage/common$ getfacl
file-created-with-default-acl-for-group-and-default-mask
# file: file-created-with-default-acl-for-group-and-default-mask
# owner: skubriev
# group: __USERS__
user::rw-
group::rwx #effective:rw-
group:__USERS__:rwx #effective:rw-
mask::rw-
other::r--

При создании файла на при монтированном через nfs ресурсе файл создается
с маской mask::rw-

user@comp:/storage/common$ getfacl
file-copy-from-home-with-default-acl-for-group-and-default-mask
# file: file-copy-from-home-with-default-acl-for-group-and-default-mask
# owner: skubriev
# group: __USERS__
user::rw-
group::rwx #effective:r--
group:__USERS__:rwx #effective:r--
mask::r--
other::r--

При копировании на при монтированный через nfs ресурс файл создается с
маской mask::r--

Где здесь логика ?

И почему наследование не работает, ну или работает но при этом
подчиняется системному umask.

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

Я так понимаю тут тесно переплелись несколько компонентов системы
начиная системными вызовами заканчивая NFS.

Но ведь не может быть такого, что есть в Windows , с некоторых пор
работает в mac os и не может быть реализовано на linux.

А как вы решаете эту проблему?

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5140610D...@skubriev.ru

[Sergey Spiridonov]

Привет Владимир

On 03/13/2013 12:20 PM, Владимир Скубриев wrote:
> Очень не хочется городит велосипед. Я имею в виду, что пока вижу только
> одно решение данной проблемы отдельным демоном следить за правами или
> изменениями в файловой системе и фиксить автоматом права на появляющиеся
> новый файлы.

Когда-то я столкнулся с такой же или похожей проблемой. Сейчас пишу
демон для этих целей. Можно посмотреть на какой-нибудь существующий
inotify - демон и доточить под эти нужды.
--
C уважением, Сергей Спиридонов

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khpout$3t5$1...@ger.gmane.org

[Владимир Скубриев]

On 03/13/2013 03:46 PM, Sergey Spiridonov wrote:
> Привет Владимир
>
> On 03/13/2013 12:20 PM, Владимир Скубриев wrote:
>> Очень не хочется городит велосипед. Я имею в виду, что пока вижу только
>> одно решение данной проблемы отдельным демоном следить за правами или
>> изменениями в файловой системе и фиксить автоматом права на появляющиеся
>> новый файлы.
>
> Когда-то я столкнулся с такой же или похожей проблемой. Сейчас пишу
> демон для этих целей. Можно посмотреть на какой-нибудь существующий
> inotify - демон и доточить под эти нужды.

Привет! Да я в курсе на счета демона и inotify. По крайней мере задание
так и звучало:

Написать демона, разобраться с inotify - найти выход из положения. Но
ведь теплоходостроение - не сложный путь! А я легких путей не ищу.

Кстати ты на каком этапе по написанию "демона" ?

Можешь поделится наработками ? Дабы я лишнюю работу не делал ?

Могу конечно и присоединится к работе.

У самого задача так стоит.

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

Получается что наша gnu/линукс которая так славится своей unixway
философией загнала нас в тупик из которого пока выхода нет - кроме как
сочинять велосипед.

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

Просто я еще не пробывал.

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/51406DF7...@skubriev.ru

[Eugene Berdnikov]

On Wed, Mar 13, 2013 at 04:15:51PM +0400, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ wrote:
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ gnu/О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ unixway
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ - О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫?

О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ "copy". О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ API, О©╫ нёО©╫
О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ nfs,
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫, О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ (О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫), О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫...

> О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ umask О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ ?
>
> О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫"?
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130313124...@protva.ru

[Sergey Spiridonov]

Привет Владимир

On 03/13/2013 01:15 PM, Владимир Скубриев wrote:
> On 03/13/2013 03:46 PM, Sergey Spiridonov wrote:

> Кстати ты на каком этапе по написанию "демона" ?

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

> Можешь поделится наработками ? Дабы я лишнюю работу не делал ?

Планирую через пару дней что-то рабочее иметь. Выложу куда-нить если ещё
надо будет.

--
С уважением, Сергей Спиридонов

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khq0q5$jkh$1...@ger.gmane.org

[Владимир Скубриев]

On 03/13/2013 06:00 PM, Sergey Spiridonov wrote:

Привет Владимир

On 03/13/2013 01:15 PM, Владимир Скубриев wrote:

On 03/13/2013 03:46 PM, Sergey Spiridonov wrote:

Кстати ты на каком этапе по написанию "демона" ?

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

Можешь поделится наработками ? Дабы я лишнюю работу не делал ?

Планирую через пару дней что-то рабочее иметь. Выложу куда-нить если ещё надо будет.

У тебя решение с использованием inotify-wait ?

Я сейчас сделал вот это:
http://en.positon.org/post/A-solution-to-the-umask-problem%3A-inotify-to-force-permissions

Сейчас проверяю как оно работает.

[Sergey Spiridonov]

Привет Владимир

On 03/14/2013 05:59 AM, Владимир Скубриев wrote:

> У тебя решение с использованием inotify-wait ?

Я написал демон на c++. В принципе уже работает, но хочу красоту навести.
--
Сергей

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khsk7j$36m$1...@ger.gmane.org

[Владимир Скубриев]

On 03/14/2013 05:44 PM, Sergey Spiridonov wrote:

Привет Владимир

On 03/14/2013 05:59 AM, Владимир Скубриев wrote:

У тебя решение с использованием inotify-wait ?

Я написал демон на c++. В принципе уже работает, но хочу красоту навести.

Я вчера сделал при помощи inotifywait И скрипта в init.d

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

Как только наведешь красоту пиши в рассылку будем пробывать.

Кстати ты используешь inotifywait или напрямую с функцией ядра работаешь?

Ты продумывал демона с точки зрения работы с расширенными ACL, чтобы он и группам расширенных acl тоже правам добавлял write ?

Я остановился на работе без acl, т.к. в моем случае они по сути не нужны.

Хотел еще уточнить кое что уточнить и спросить я прав вообще в своём рассуждении?

Проблемы с созданием общего каталога в линукс связаны с:

1. Установкой прав по умолчанию в среде linux на вновь создаваемые и копируемые файлы. Маска также действует на расширенные разрешения ACL в том числе заданные по умолчанию (default acl).

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

Это связано в первую очередь с безопасностью.

Вновь создаваемым файлам как правило не необходимо иметь право выполнения. А основной группе в которую входит пользователь не обязательно сразу давать возможность записи в только что созданный пользователем файл. И это де факто стандарт в мире линукс. Файл создаётся с правами 644 а папка с правами 755.

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

В функции системного вызова open() есть параметр - mode. Значение этого параметра влияет на результирующие права.

Это можно увидеть если запустить операции с файлами при помощи отладчика strace:

Вызов метода open() при создании файла:
open("file-new", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3

Вызов метода open() при копирование:
open("./file-copy", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4

По умолчанию при создании нового файла системные утилиты и практически все программы вызывают его с значением параметра mode =     666 для файла и mode = 777 для папки (если создается папка). Новые объекты создаются с полными правами. Но после создания нового объекта в ФС ядро применяет к нему маску. Таким образом новые файлы и папки создаются с правами 0644 и 0755 с маской установленной по умолчанию (0022).

Рассмотри применение маски. Это операция логического умножения.

Делаем инверсию бит системной маске: ~0022 -> 7755 (инверсия бит)
Далее выполняем побитовое логическое И: 7755 ? 0666 ->0644
Совет насчет вычитания в корне неверен! (0666-0202=0644) это случайное совпадение!

А утилита копирования вызывает этот системный метод с значением параметра равному правам исходного файла/папки. И они как правило могут отличатся от значения используемого при создании объектов файловой системы.

Если учесть то, что при создании файла пользователем с значением системной маски по умолчанию (0022) убирается право записи для основной группы, то при копировании такого файла на общий ресурс пользователи входящие в эту группу не смогут изменить данный файл пока владелец или суперпользователь не установит для группы право на запись. Это особенность работы системы по умолчанию.

В данном случае у нас есть два пути для решения данной проблемы:

1. Изменить на всех компьютерах в сети значение umask таким образом, чтобы маска не отсекала право на запись для группы.

2. Сделать так, чтобы в система на сервере сама следила за новыми файлами и правила их разрешения.

По сути не один из способов не является элегантным, так как в первом случае нарушается безопасность пользователей а во втором мы "изобретаем велосипед"

Но мы для решения задачи выберем второй вариант.

Для этого нам потребуется:

1. Установить пакет с специальной программой использующей API ядра ОС для слежения за изменениями файлов.

aptitude install inotify-tools

2. Создать скрипт запускающий нужную нам утилиту в режиме демона(в фоне).

nano /usr/local/bin/inotifywait.sh:

#!/bin/sh
# Take the directory name as argument
# Source from:
# http://en.positon.org/post/A-solution-to-the-umask-problem%3A-inotify-to-force-permissions

# Когда он запускается то есть почти 100 времени одного ядра,
# но в течении минуты все стабилизируется и нагрузка снижается до минимального значения

inotifywait -mrq -e CREATE -e MODIFY -e CLOSE -e MOVE --format %w%f "$1" | while read FILE
do
        chmod g=u "$FILE"
done


3. Создать скрипт запуска init.d. Слово "common"  - это название папки в которой мы будем следить за новыми файлами.

/etc/init.d/inotifywait-common

#! /bin/sh

# PLease удостоверится, что папки и подпапки имеют бит GID (s)
# find /path/to/dir -type d -exec chmod g+s {} \;
# find $PATH_TO_FOLDER -type d -exec chmod g+s {} \;

# Укажите папку в которой следить за изменениями в файлах
PATH_TO_FOLDER=/storage/shares/common

case "$1" in
  start|"")

        rm -f /tmp/inotifywait.log
        /usr/local/bin/inotifywait.sh $PATH_TO_FOLDER >/tmp/inotifywait.log 2>&1 &
        ;;

  restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;

  stop)
        # killall inotifywait ???
        ;;

  *)
        echo "Usage: inotifywait.sh [start|stop]" >&2
        exit 3
        ;;
esac

:


4. Выполнить включение авто запуска данного скрипта при старте системы.

update-rc.d inotifywait-common defaults


5. Изменить значение параметра влияющего на работу API ядра inotify.

Сначала проверим сколько файлов и каталогов у нас используется сейчас:

ls -R /storage/shares/common | grep -c ''

665291

Соответственно значения  1000000 будет более чем достаточно для этой папки на первое время.

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

Вносим изменения в sysctl.conf

echo " ">> /etc/sysctl.conf
echo "#  This specifies a limit on the number of watches that can be associated with each inotify instance.">> /etc/sysctl.conf
echo " fs.inotify.max_user_watches=1000000" >> /etc/sysctl.conf

Также стоит отметить, что файлы создаваемые пользователями принадлежат основной группе пользователя. При создании файла/папки на общем ресурсе в нашем случае NFS нам необходимо помимо разрешений для группы изменять также и саму группу объекта ФС.

Для решения данной задачи будем использовать GUID бит для нашего родительского каталога. Данный бит также будет наследоваться всеми дочерними каталогами и файлами

Установим его нашему сетевому каталогу:

chown g+s /storage/shares/common

Пару слов о расширенных списках контроля доступа в Линукс:

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

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

В ACL есть понятие прав по умолчанию.

Так вот если они заданы, то

1. Они наследуются дочерними каталогами

2. К ним также применяется системная маска, то есть если в системной маске каких бит доступа нет, то и в расширенных acl этих бит доступа не будет!

Если они не заданы, то

1. Новому объекту задаются права пользователя, группы и других при помощи стандартного системного механизма.

2. К ним также применяется системная маска, то есть если в системной маске каких бит доступа нет, то и в расширенных acl этих бит доступа не будет!

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

И вообще их можно использовать для задания дополнительных прав пользователей.

А default acl нужно использовать для наследования прав дополнительных пользователей и групп дочерними объектами, но при этом права для новых файлов вне зависимости от того, как они создаются будут обрезаться системной маской.

В итоге самое главное - это системная маска.

В связи с этим вопрос можно ли изменив значение системной маски изменить поведение наследования расширенных и обычных прав ?

ОТВЕТ: ДА, но это повлияет на безопасность, так как файлы могут быть доступны на запись не только его владельцу.

Пожалуйста! Поправите меня если я где то ошибаюсь?