How to restrict a user to one folder and not allow them to move out his folder
I have ubuntu server on digitalocean and I want to give someone a folder for their domain on my server, my problem is, I don’t want that user to see my folders or files or to be able to move out their folder. How can I restrict this user in their folder and not allow to him to move out and see other files/directories ?
chmod is not good solution because i can’t use it for all the folder in my server i used before he can move out his folder
actually i have no idea about group because i didn’t use it before can you just explain to me what the benefit of it ?
3 Answers 3
I solved my problem by this way:
Create a new group
$ sudo addgroup exchangefiles Create the chroot directory
$ sudo mkdir /var/www/GroupFolder/ $ sudo chmod g+rx /var/www/GroupFolder/ Create the group-writable directory
$ sudo mkdir -p /var/www/GroupFolder/files/ $ sudo chmod g+rwx /var/www/GroupFolder/files/ Give them both to the new group
$ sudo chgrp -R exchangefiles /var/www/GroupFolder/ after that I went to /etc/ssh/sshd_config and added to the end of the file:
Match Group exchangefiles # Force the connection to use SFTP and chroot to the required directory. ForceCommand internal-sftp ChrootDirectory /var/www/GroupFolder/ # Disable tunneling, authentication agent, TCP and X11 forwarding. PermitTunnel no AllowAgentForwarding no AllowTcpForwarding no X11Forwarding no Now I’m going to add new user with obama name to my group:
$ sudo adduser --ingroup exchangefiles obama Now everything is done, so we need to restart the ssh service:
notice: the user now can’t do any thing out file directory I mean all his file must be in file Folder.
@alper This works on sftp tool. When user connect to server via sftp tool like filezilla, he can see his directory and can’t go to other directories.
This worked well for me, but I want to point out to follow the directions exactly. The ChrootDirectory needs to be the directory ABOVE whatever subdirectory you want the user to be able to, say, upload files to. I know this is in the answer, but it drove me crazy because I kept telling it to do /data/files/, instead of /data/ . How this helps sometimes.
@Richard That is exactly the thing I was wondering, if the parent root directory is really necessary. At first sight it seems redundant.
Restrictions are a sensible issue, and it must be defined consistently. What you can do is to define a restricted shell for the user as his default shell.
For example, setting /bin/rksh (a restricted kornshell) instead of the user’s predefined shell as the default shell for that user in /etc/profile .
NOTE: if the executable with this name is not existing on your system then create a hard link ln /bin/ksh /bin/rksh and ksh will determine by its name whether it’s restricted or not.
The restricted shell will (for example) prevent doing a cd command, or specifying a command with a / (an explicit path) in the invocation, and it disallows changing the PATH , SHELL , or ENV variable, and output redirections are also prohibited.
You can still provide predefined shell scripts to the user that will (under the script implementors control!) allow the user to run that specific script(s) in an unrestricted environment.
Ограничить пользователю доступ в один из своих каталогов
Привет! Возможно ли ограничить доступ пользователю в один из своих каталогов, используя пароль или что-то вроде. Ситуация — есть удаленный сервер, на котором есть пользователь user — это общая учетка для нескольких пользователей, которые подключаются по ssh. В домашней директории этого пользователя есть разные файлы, которые могут эти ssh-пользовватели просматривать. Схема устоявшаяся, и что-то менять будет сложно. Нужно в этом же ~user сделать каталог, вход в который будет ограничен для всех этих ssh-пользователей кроме некоторых. Внутри этого каталога в vitualenv будет развернуто несколько проектов на python если это важно. Возможно ли такое? В силу специфики администрирования этого удаленного сервера заводить еще одного пользователя не желательно, а запретить всем, кто подключается по ssh запускать скрипты из этого каталога с окружением python устно или письменно просто нереально. Буду очень благодарен за ваши советы.
А в чем проблема? Сделай там каталог под другим юзером (например, root) и убери права чтения и перехода: chmod 700 secret_dir . user туда зайти не сможет; правда сможет удалить.
В силу специфики администрирования этого удаленного сервера заводить еще одного пользователя не желательно
Вперёд и с песней, и не одного, а для каждого людя по учётке. Ибо нефиг так было делать и чем раньше это исправить, тем проще будет жить.
Ещё, как вариант, можно уволиться, сбежать и притвориться мёртвым.
Вперёд и с песней, и не одного, а для каждого людя по учётке. Ибо нефиг так было делать и чем раньше это исправить, тем проще будет жить.
Кстати, да, поддержу этого анонимуса.
Во-первых, несколько пользователей. С общей группой (пусть будет foobar) и общей домашней директорией.
А потом — для этой директории.
cd /home/user chown -R nobody:foobar . chmod -R ug+rw . find . -type d -exec setfacl -d -m u=rwx,g::rwx,o::rx <> \; Получаем, что все юзеры могут иметь доступ к /home/user (потому что группа общая), а через ACL задано, что права на вновь созданные файлы должны быть не 644, а 664.
А вот после этого можно тому самому каталогу присвоить виртуального юзера-владельца ( chown -R secret_user secret_dir ; очевидно, python запускать под ним же), разрешить доступ к каталогу только владельцу (т. е. chmod -R go-rwx secret_dir ), а доверенным юзерам через sudo разрешить запускать оболочку от имени виртуального юзера.
intelfx ★★★★★ ( 25.09.14 03:24:38 MSK )
Последнее исправление: intelfx 25.09.14 03:28:39 MSK (всего исправлений: 4)
Если непустая, удалить не сможет (нужно сначала удалить всё, что внутри, а для этого нужно прочитать).
Переименовать, переместить — этого хватит.
acl случаем не подойдет?
Kroz , intelfx , FIL и anonymous ! Спасибо за ваши советы, предлагаемые вами варианты логичны, но, увы, сложно осуществимы — все с водится к тому, что у меня должна быть группа пользователей или пользователь, который будет иметь доступ к этому каталогу, но мне нужно сделать как-то «автономно» — удаленному пользователю должно быть достаточно простого доступа к этой общей учетке по ssh. Касаемо «личных» учеток — они есть, они все в разных группах (т.е. user1 в группе user1, user2 в user2 и т.д.), и сейчас вопрос дать\забрать права на вход под общей группой решается на уровне ключей в authorized_keys. Предлагаемые варианты разделения прав на уровне групп пользователей или sudo проблеатичны тем, что нужны рутовые права, что гораздо сложнее той пары однострочников для работы с ключами ssh, которые есть сейчас. Хочется сделать, отдать тем ребятам что будут подключаться и забыть — пусть они прописывают ключи если кому-то понадобится и передают пароли от этого защищенного каталога, и все это без необходимости рутовых прав.
общая учетка для нескольких пользователей
Идиот. А значит — должен страдать.
Учетки есть у каждого пользователя, плюс есть общая чтоб никто не путался с правами на каталоги и т.д.
дай приватному каталогу другую группу, в которую входит только один пользователь, а всем общим каталогам — общую группу, в которую они все входят, или пользуйся acl
Это хороший вариант, но тогда каждого нового пользователя придется добавлять в эту общую группу, а хочется обойтись и без этого — моя задача «сделать и забыть», а тот кто будет заводить новых пользователей вряд ли запомнит что нужно еще и в новую группу добавить.
общая чтоб никто не путался с правами на каталоги и т.д.
Замени на пачку внешних утилит, синхронизирующих необходимые каталоги, которые должны быть типа-общими. Не делай больше общих учёток. Вообще сдаётся мне, что ты хочешь сделать VCS-репозиторий и разделённые права доступа к нему, но даже не через жопу, а фиг знает как.
моя задача «сделать и забыть», а тот кто будет заводить новых пользователей вряд ли запомнит что нужно еще и в новую группу добавить
колхоз — главная проблема. тот кто будет заводить нового пользователя проклянет тебя, если твоё колхозное решение выбивается из стандартной практики администрирования. а файл редми.тхт в /root с одной строчкой улучшит твою карму ещё больше
Нет, это вообще «личный проект», упрощение некоторых рутинных дейтсвий, там есть общие для большой группы людей скрипты и скрипты, которые должны быть общими для небольшой группы людей.
Так вот я хочу сделать решение, «прозрачное» для того, кто будет заводить нового пользователя. Новый пользователь просто потом генерит себе ключ чтоб ходить под общей учеткой, и все это абсолютно не касается «рута».
Мопед, в общем то, не мой — когда я «пришел» практика общих учеток уже была введена повсеместно. Соответственно мне надо как-то в этот процесс вклиниться. Само собой, делай я все сам изначально сделал бы иначе, через общие группы.
VCS-репозиторий и разделённые права доступа к нему
Нет, такого мне не требуется.