Я хотел бы перечислить все каталоги, для которых у пользователя или группы есть полномочия записи.
Я нашел этот вопрос на ServerFault, но он обращается к Windows Server, таким образом, я оптимистичен, что существует что-то лучше для нас в сообществе Linux. В то же время я понимаю, что существует рекурсивное скручивание к этому вопросу, который может представить его невозможный без продолжительного сценария.
Я знаю о следующих полезных командах:
cut -d : -f 1 /etc/group
cut -d : -f 1 /etc/passwd
getent passwd user-name| cut -d: -f 6
ls -la
Однако, когда у меня нет подсказки, какова цель пользователя, было бы хорошо потянуть список ВСЕХ каталогов, для которых они имеют разрешение записи и начинают озираться оттуда. Если ничто иное это - суперполезный аудит..
Если это помогает понять мою цель, я наследовался (или по крайней мере работаю в качестве няни?) несколько систем после того, как наш SysAdmin занял новую позицию. Таким образом, я пытался понять эволюцию этих двух систем, такой как, какое программное обеспечение установлено, и где (.. тьфу), где различные файлы конфигурации живут, и теперь, какие различные группы и пользователи были созданы - включая каталоги, в которые им разрешают записать. Обычно я могу найти такие полезные терминальные команды здесь на askubuntu, но не находящий этого я думал, что буду идти вперед и спрашивать.
Точной системой является Ubuntu 10.04.2, но мы также поддерживаем Ubuntu 12.04.5, таким образом, самое агностическое версией решение было бы лучшим. Заранее спасибо за любую справку.
[Обновление: Начальные результаты для двух быстрых ответов]
Стоит отметить, что я зарегистрирован, как поддерживают их, и /
был мой рабочий каталог. Кроме того, они заняли сопоставимое количество времени для выполнения.
Объединенная команда @Rinzwind вложила следующий вывод приблизительно 5,5 минут.
root@tatooine:/# sudo find -type d \( \( -user ftpgisdata -perm /u=w \) -o \( -group ftpgisdata -perm /g=w \) -o -perm /o=w \)
./tmp
./tmp/.ICE-unix
./tmp/.X11-unix
find: `./proc/6594/task/6594/fd/5': No such file or directory
find: `./proc/6594/task/6594/fdinfo/5': No such file or directory
find: `./proc/6594/fd/5': No such file or directory
find: `./proc/6594/fdinfo/5': No such file or directory
./var/tmp
./var/lib/php5
./var/crash
./var/lock
./home/ftpgisdata
./home/ftpgisdata/.ssh
./home/ftpgisdata/.cache
./home/sitename-i-changed.com/wp-content/profile-pics
./dev/shm
Пересмотренная команда @Oli получает что-то очень похожее, также приблизительно за 5,5 минут..
root@tatooine:/# sudo find / -type d -print0 | sudo -u ftpgisdata xargs -0 sh -c 'for p; do [ -w "$p" ] && echo "$p"; done' -
/tmp
/tmp/.ICE-unix
/tmp/.X11-unix
find: `/proc/15541': No such file or directory
find: `/proc/15542': No such file or directory
find: `/proc/15543': No such file or directory
find: `/proc/15567': No such file or directory
find: `/proc/15568/task/15568/fd/5': No such file or directory
find: `/proc/15568/task/15568/fdinfo/5': No such file or directory
find: `/proc/15568/fd/5': No such file or directory
find: `/proc/15568/fdinfo/5': No such file or directory
/var/tmp
/var/lib/php5
/var/crash
/var/lock
/home/ftpgisdata
/home/ftpgisdata/.ssh
/home/ftpgisdata/.cache
/home/sitename-i-changed.com/wp-content/profile-pics
/dev/shm
Ответ @PeterCordes также возвратил подобные результаты приблизительно через 5,5 минут..
root@tatooine:~# username_to_check=ftpgisdata base_dir=/ # for example
root@tatooine:~# sudo -u "$username_to_check" find "$base_dir" -type d -writable 2>/dev/null ## GNU find, not POSIX
/tmp
/tmp/.ICE-unix
/tmp/.X11-unix
/proc/7159/task/7159/fd
/proc/7159/fd
/proc/7159/map_files
/var/tmp
/var/lib/php5
/var/crash
/var/lock
/home/ftpgisdata
/home/ftpgisdata/.ssh
/home/ftpgisdata/.cache
/home/sitename-i-changed.com/wp-content/profile-pics
/dev/shm
Разработка, что может сделать пользователь, трудна, если Вы не тот пользователь. Можно протестировать различные вещи (владелец, та же группа, и т.д.), но ACL мог бы применяться, в монтировании не могло бы быть никаких полномочий, кто знает. Это твердо.
Если можно превратиться в того пользователя, Вы можете test -w <path>
видеть, могут ли они записать. Это с такой скоростью, как просто не смотрит на inode, но это возможно с sudo
.
sudo -u oli test -w <path> && echo "HOORAY"
Мы можем затем squirl это на бэкенд find
. Вместо просто использования -exec
для изменения на oli пользователя много раз и снова (см. прошлые изменения) мы передаем все по каналу в xargs экземпляр, работающий как oli. Это намного быстрее.
sudo find / -type d -print0 | sudo -u oli xargs -0 -I{} sh -c 'test -w "$0" && echo "$0"' {}
Несколько оптимизированный (но визуально более дряблый) версия этого включает уменьшение объема подокружения xargs, работает путем передачи по каналу потока путей к небольшому числу подоболочек удара. Это, несомненно, быстрее для больших поисков.
sudo find / -type d -print0 | sudo -u oli xargs -0 sh -c 'for p; do [ -w "$p" ] && echo "$p"; done' -
В чате мы пришли к следующим инструкциям для пользователя и группы:
sudo find / -type d -user rinzwind -perm /u=w
sudo find / -type d -group rinzwind -perm /g=w
sudo find / -type d -perm /o=w
Или объединение все три в один:
sudo find -type d \( \( -user rinzwind -perm /u=w \) -o \( -group rinzwind -perm /g=w \) -o -perm /o=w \)
Без / это ищет текущий каталог.
Занял меньше чем 2 секунды на 67 ГБ данных по моей системе ;)
Ответ в процессе строительства, быть терпелив
Тестирование на себя
можно протестировать полномочия записи на себя со следующим кодом:
[ -w /home/$USER ] && echo yes # using home directory as example
флаг Using -d
для теста, мы можем протестировать, если что-то - каталог.
Знание всего это и find
мы можем сделать
find /home/ -print0 2> /dev/null | while IFS="" read -r -d "" file ; do [ -d "$file" ] && [ -w "$file" ] && echo "$file" is writeable ; done
примечание Стороны: Очевидно, если Вы получаете ошибки разрешения с находкой, Вы не можете считать тот файл, следовательно нет никакой причины произвести те ошибки, следовательно перенаправление к dev пустому указателю. Очевидно, это не будет работать, если мы захотим узнать полномочия для пользователей кроме себя, и примечание - / домой является просто примером здесь. Таким папкам как /var
действительно совместно использовали папки между многочисленными пользователями
Тестирование на других
, можно было использовать stat
на каждый файл эти find
, находит, и фильтруйте его с awk
find /var -type d -exec stat --format '%g %n' {} \; 2> /dev/null | awk '$1=='1000'{print}'
Здесь, я фильтрую для числового идентификатора моего собственного пользователя, 1000, но это мог быть идентификатор любого пользователя. Конечно, можно играть с опциями, использовать название группы вместо числовых идентификаторов. Это - что-то, что является очень гибким и адаптируемым к цели, в которой Вы нуждаетесь
Маленькие корректировки
, Таким образом, я заметил, что Вы упоминаете, что были зарегистрированы как корень. Вот вывод моей команды, где я файлы статистики и печатаю их название группы и имя файла, затем отфильтровываю использование AWK соответствующим названием группы.
$ find /proc -type d -exec stat --format '%G %n' {} \; 2> /dev/null | awk '$1=="syslog"{print}'
syslog /proc/560
syslog /proc/560/task
syslog /proc/560/task/560
syslog /proc/560/task/560/net
syslog /proc/560/task/560/attr
syslog /proc/560/task/562
syslog /proc/560/task/562/net
syslog /proc/560/task/562/attr
syslog /proc/560/task/563
syslog /proc/560/task/563/net
syslog /proc/560/task/563/attr
syslog /proc/560/task/564
syslog /proc/560/task/564/net
syslog /proc/560/task/564/attr
syslog /proc/560/net
syslog /proc/560/attr
^C
Если у Вас есть GNU, находят, можно использовать -writable
тест (отмечают написание, это не writeable
). Это использует access(2)
системный вызов вместо того, чтобы просто пытаться изобразить вещи из рассмотрения полномочий, таким образом, это работает правильно с ACLs. (Но мог бы повредиться на NFS с идентификационными отображениями).
Это также найдет каталоги, которые являются записываемыми пользователем благодаря тому, чтобы быть членом вторичной группы. (например, каталог в /usr/local
записываемый пользователями в admin
группа или что-то как chown root:users /data/share && chmod 2775 /data/share
, где некоторые учетные записи являются членами users
группа.)
username_to_check=peter base_dir=/ # for example
sudo -u "$username_to_check" find "$base_dir" -type d -writable 2>/dev/null ## GNU find, not POSIX
Будут ошибки когда find
каталоги обнаружения, в которые не может убывать пользователь, таким образом, мы перенаправляем ошибки к /dev/null
.
Это не найдет каталогов, которые являются записываемыми но внутренними каталогами без, выполняют разрешение, потому что find
при выполнении, поскольку пользователь не может пересечь более высокие каталоги. Однако, если процесс, которым они владеют, будет запущен в таком каталоге, то они смогут записать в него с относительными путями. (или они овладевают открытым дескриптором файла к такому каталогу, они могут использовать openat(2)
). pwd
не будет работать, если у них не будет исполнительного разрешения на одном из компонентов каталога полного пути, таким образом, это не общая установка.
Это также пропускает записываемые каталоги, которые являются внутренним исполняемым файлом, но не читаемыми каталогами. Для работы вокруг тех ограничений, вероятно, работайте find -type d
как корень и использование find -writable
как пользователь для проверки получающихся путей. Это могло бы быть более эффективно, чем использование цикла оболочки [ -w "$f" ]
.
POSIX find(1)
имеет гораздо меньше опций, чем GNU находит. Если Ваш сценарий должен быть портативным к POSIX, является, вероятно, самым легким передать по каналу во что-то еще, что проверяет полномочия, как оболочка с [ -w "$f" ]
(см. другой ответ, который предлагает это.)