Причины являются главным образом историческими, как сказали другие. /var
использовался для системных данных, которые изменяются все время, например, файлы кэша, журналы, данные во время выполнения (файлы блокировки, например), устройство хранения данных почтового сервера, буферизация принтера, и т.д. В основном для всего материала, который не может быть вставлен /usr
(потому что это содержит локальные данные), не сторонние программы, которые входят /opt
, и не отбрасываемо и энергозависим, поскольку они входят /tmp
.
Как разработанный Unix/Linux, это стало грязным местом с мешаниной различных отличающихся соединенных каталогов. Была тенденция в последние годы для перемещения некоторых вещей из туда, особенно довольный служил машиной (в который теперь согласно [должен войти Стандарт Иерархии Файловой системы 2.3, p.15] /srv
, не в /var/www
).
Подобная вещь произошла с /var/run
несколько лет назад - со сконцентрированным усилием по нескольким дистрибутивам, это было перемещено от /var/run
в /run
который сплавленный вместе функции ранее используемого /var/lock
, /var/run
и /dev/shm
.
Можно установить ACL по умолчанию, чтобы дать эту группу execute-if-executable (X), но не прочитать разрешение.
setfacl -R -d -m group:mygroup:X .
Таким образом, недавно созданные файлы не будут читаемы группой, но группа сможет пересечь каталоги. Однако группа не сможет перечислить содержание каталога. Я думаю, что это является самым близким, можно сделать с Solaris/Linux ACLs.
Так как этот ACL более строг, чем, что Вы хотите, безопасно применить этот ACL и позже добавить разрешение чтения к каталогам. Можно сделать это автоматически через inotify, например, со следующим incrontab:
/path/to/directory IN_CREATE /path/to/script $@
где сценарий содержит
#!/bin/sh
if [ -d "$1" ]; then setfacl -m group:mygroup:r -- "$1"; fi
Другой подход должен создать представление того дерева каталогов с различными полномочиями с bindfs. Bindfs поддерживает различные полномочия для каталогов и регулярных файлов.
bindfs -g mygroup -p gd=rx,gf= /path/to/original/root /path/to/mount/point
Если Вы хотите, чтобы это полномочия было осуществлено для всех файлов/каталогов, Вы создаете в будущем, используете umask
как предложено в первом комментарии к Вашему вопросу.
Если это - одноразовое действие - Вы уже имеете в распоряжении каталоги и файлы и хотите исправить полномочия - можно использовать find
команда в высокоуровневом каталоге:
# Give all permissions to all for the directories and
# Revoke the permission for others
find . -type d -exec chmod +rwx,o-rwx {} +
# Unset all premissionas for all files and
# Give read & write premission to the owners
find . -type f -exec chmod -rwx,u+rw {} +
Можно было думать о планировании этих команд с cron
, но я предполагаю, что это не было бы прекрасной идеей. Например, невладельцы могли считать файлы в окне времени до следующего расписания cron
задание.
umask
? (это имеет поля для пользователя / группа / другой, но не для каталога/файла).
– ctrl-alt-delor
26.08.2013, 15:43
umask
не будет полезно.
– Barun
26.08.2013, 16:45
Вы могли заняться решением от немного отличающегося угла и использовать что-то такой Incron, или Inoticoming (последний является инструментом Debian, который был портирован ко многим дистрибутивам). С обоими из них можно смотреть каталоги, и разрешение файла действия изменяется на определенных ключевых событиях. Согласно incron это требует ядра 2.6.13 или позже с inotify, скомпилированным в. Это появляется на человечности, debian и Fedora как пакеты, таким образом, это легко установлено (и похож на него, портирован ко многим дистрибутивам).
Существует хорошая статья об использовании incron inotify на nixCraft