Предоставьте пользователю доступ для чтения / записи только к одному каталогу

Я использую сервер, и мне нужно предоставить доступ на чтение / запись к определенному каталогу одному пользователю. Я пробовал следующее:

sudo adduser abcd
sudo groupadd abcdefg
chown -R .abcdefg /var/www/allowfolder
chmod -R g+rw /var/www/allowfolder
usermod -a -G comments abcd

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

Как настроить разрешения, чтобы пользователь мог только читать и писать в определенную папку? Пользователь также должен иметь возможность запускать такие программы, как mysql.

permissions files account-restrictions

— Manishearth
источник

Краткий ответ: используйте chroot.

— Крис Даун

@Chris Уточните это в ответе? Маниш и я боролись с этим и не могли заставить его работать.

— Отменить

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

— Жиль "ТАК - перестань быть злым"

@ Жиль Хмм. Насколько я могу судить, это стандартная установка mysql из apt-get (не моя система, а Undo).

— Manishearth

Ответы:

Отрицательные ACL

Вы можете запретить пользователю доступ к определенным частям файловой системы, настроив списки контроля доступа . Например, чтобы гарантировать, что пользователь abcdне может получить доступ к любому файлу в /home:

setfacl -m user:abcd:0 /home

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

корневой

Чтобы получить положительный контроль над тем, что abcdвидите, установите chroot , то есть ограничьте пользователя поддеревом файловой системы.

Вам нужно сделать все файлы, которые нужны пользователю (например, mysqlи все его зависимости, если вы хотите, чтобы пользователь мог запускаться mysql) под chroot. Скажите, что путь к chroot есть /home/restricted/abcd; mysqlпрограмма должна быть доступна под /home/restricted/abcd. Символическая ссылка, указывающая вне chroot, бесполезна, потому что поиск символической ссылки затронут тюрьмой chroot. Под Linux вы можете использовать bind mounts:

mount --rbind /bin /home/restricted/abcd/bin
mount --rbind /dev /home/restricted/abcd/dev
mount --rbind /etc /home/restricted/abcd/dev
mount --rbind /lib /home/restricted/abcd/lib
mount --rbind /proc /home/restricted/abcd/proc
mount --rbind /sbin /home/restricted/abcd/sbin
mount --rbind /sys /home/restricted/abcd/sys
mount --rbind /usr /home/restricted/abcd/usr

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

Чтобы ограничить пользователя chroot, добавьте ChrootDirectoryдирективу /etc/sshd_config.

Match User abcd
    ChrootDirectory /home/restricted/abcd

Вы можете проверить это с: chroot --userspec=abcd /home/restricted/abcd/ /bin/bash

Рамки безопасности

Вы также можете использовать каркасы безопасности, такие как SELinux или AppArmor. В обоих случаях вам нужно написать довольно деликатную конфигурацию, чтобы убедиться, что вы не оставляете никаких дыр.

— Жиль "ТАК - прекрати быть злым"
источник

Не может ли намного более простой способ дать права на чтение и запись для определенного каталога через создание групп? Например, он мог создать новую группу и использовать chown, чтобы сделать владельца группы каталогов созданной группой и добавить пользователя в группу. Наконец, дайте директории права на чтение и запись для групп.

— Касим

@Qasim Для этого необходимо, чтобы все файлы имели свои права доступа и владельца, установленные по желанию. Есть так много вещей, которые могут пойти не так (файлы, скопированные из других источников или извлеченные из архива с сохраненными разрешениями, файлы, которые должны принадлежать другой группе, файлы, которые не должны быть доступны для чтения в группе, пользователи, которые делают ошибки или могут ') не стоит заботиться о том, чтобы доступность групп оставалась такой, как хотелось бы…) чтобы группы действительно не решали эту проблему.

— Жиль "ТАК - прекрати быть злым"

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

— Касим

@Qasim Каждый файл в /var/www/allowfolderи его подкаталогах должен быть доступен, а не только /var/www/allowfolderсам по себе. И наоборот, другие файлы не должны быть доступны. Фактически решение, основанное исключительно на правах доступа к файлам и ACL, не может полностью выполнить требования: оно, по крайней мере, позволило бы пользователю проверить, существует ли данное имя /var/www, так как ему нужно иметь x разрешение на /var/wwwдоступ /var/www/allowfolder.

— Жиль "ТАК - перестать быть злым"

О, хорошо, я вижу, но если мы исключим из этого каталог / var и допустим, что мы говорим о нормальном каталоге в каталоге / home / user?

— Касим

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

Это было написано на месте; Я сейчас не перед машиной UNIX. В этом примере есть директория dirс тремя файлами: a, b, c, и ls. Первые три являются обычными файлами. lsявляется жесткой ссылкой на настоящий lsдвоичный файл, так что мы можем перечислять файлы, находясь в chroot.

Я собираюсь chrootв dir. (Обратите внимание, что я, вероятно, забыл некоторые каталоги в корневом каталоге.)

Вот настройка в форме вывода оболочки:

$ pwd
/home/alex/test
$ l
dir
$ ls dir
a b c ls
$ ./ls dir # does the same thing
a b c ls
$ ls /
bin boot dev etc home mnt media proc sbin sys usr var

Теперь я буду chrootв dir. В /bin/bashвыбирает аргумент , что процесс должен быть запущен с новой корневой директории. По умолчанию оно /bin/sh.

$ chroot /bin/bash dir
$ # this prompt is now from a subprocess running in the new root directory
$ PATH=/ ls
a b c ls
$ pwd
/

Теперь мы выходим из chroot:

$ exit
$ # this prompt is now from the original bash process, from before the chroot
$ pwd
/home/alex/test

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

Жесткая ссылка на файл будет продолжать работать внутри chroot, даже если к этому файлу нельзя получить доступ другими способами (это работает, потому что жесткие ссылки указывают на inode, а не на пути). Итак, чтобы позволить пользователю получить доступ, например, к mysqlкоманде, вы должны выполнить:

ln /usr/bin/mysql /path/to/chroot/target

— strugee
источник

Но разве это не потребовало бы от меня установки всей среды chroot со всеми символическими ссылками? Не проще ли выполнить команду, чтобы у нового пользователя не было доступа к другим каталогам, но такие программы, как apache, не потеряли к ним доступ?

— Manishearth

В принципе, есть ли способ (через chmod) заставить пользователя потерять доступ для чтения к остальной части fs, не влияя на доступ других пользователей?

— Manishearth

@ Manishearth нет простого пути с chmod. когда вы говорите «не будет ли легче выполнить команду ... не потерять к ней доступ», эта команда будет chroot. если вы объясните, что вы подразумеваете под «целым окружением chroot», или почему это будет проблемой, возможно, я пойму лучше. (обратите внимание , что вы можете дать доступ ко всем исполняемым с Oneliner: ln /bin/* /path/to/chroot/target)

— strugee

@Manishearth, если мой пример не имеет смысла, я бы посоветовал вам поиграть с chrootсобой или дайте мне знать, что не имеет смысла. еще лучше делай и то и другое. (и прочитайте man-страницы.)

— Струге

@Manishearth, если этот ответ помог вам достаточно, чтобы привести вас к ответу, вы должны принять его.

— стружка