LINUX.ORG.RU

Ограничить пользователю доступ в один из своих каталогов

 , ,


0

1

Привет! Возможно ли ограничить доступ пользователю в один из своих каталогов, используя пароль или что-то вроде. Ситуация - есть удаленный сервер, на котором есть пользователь user - это общая учетка для нескольких пользователей, которые подключаются по ssh. В домашней директории этого пользователя есть разные файлы, которые могут эти ssh-пользовватели просматривать. Схема устоявшаяся, и что-то менять будет сложно. Нужно в этом же ~user сделать каталог, вход в который будет ограничен для всех этих ssh-пользователей кроме некоторых. Внутри этого каталога в vitualenv будет развернуто несколько проектов на python если это важно. Возможно ли такое? В силу специфики администрирования этого удаленного сервера заводить еще одного пользователя не желательно, а запретить всем, кто подключается по ssh запускать скрипты из этого каталога с окружением python устно или письменно просто нереально. Буду очень благодарен за ваши советы.

А в чем проблема? Сделай там каталог под другим юзером (например, root) и убери права чтения и перехода: chmod 700 secret_dir. user туда зайти не сможет; правда сможет удалить.

Kroz ★★★★★ ()

В силу специфики администрирования этого удаленного сервера заводить еще одного пользователя не желательно

Вперёд и с песней, и не одного, а для каждого людя по учётке. Ибо нефиг так было делать и чем раньше это исправить, тем проще будет жить.

Ещё, как вариант, можно уволиться, сбежать и притвориться мёртвым.

anonymous ()
Ответ на: комментарий от anonymous

Вперёд и с песней, и не одного, а для каждого людя по учётке. Ибо нефиг так было делать и чем раньше это исправить, тем проще будет жить.

Кстати, да, поддержу этого анонимуса.

Kroz ★★★★★ ()

Во-первых, несколько пользователей. С общей группой (пусть будет 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 ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 4)

acl случаем не подойдет?

FIL ★★★★ ()

Kroz, intelfx, FIL и anonymous! Спасибо за ваши советы, предлагаемые вами варианты логичны, но, увы, сложно осуществимы - все с водится к тому, что у меня должна быть группа пользователей или пользователь, который будет иметь доступ к этому каталогу, но мне нужно сделать как-то «автономно» - удаленному пользователю должно быть достаточно простого доступа к этой общей учетке по ssh. Касаемо «личных» учеток - они есть, они все в разных группах (т.е. user1 в группе user1, user2 в user2 и т.д.), и сейчас вопрос дать\забрать права на вход под общей группой решается на уровне ключей в authorized_keys. Предлагаемые варианты разделения прав на уровне групп пользователей или sudo проблеатичны тем, что нужны рутовые права, что гораздо сложнее той пары однострочников для работы с ключами ssh, которые есть сейчас. Хочется сделать, отдать тем ребятам что будут подключаться и забыть - пусть они прописывают ключи если кому-то понадобится и передают пароли от этого защищенного каталога, и все это без необходимости рутовых прав.

alozovskoy ★★★★★ ()

общая учетка для нескольких пользователей

Идиот. А значит - должен страдать.

anonymous ()
Ответ на: комментарий от alozovskoy

дай приватному каталогу другую группу, в которую входит только один пользователь, а всем общим каталогам — общую группу, в которую они все входят, или пользуйся acl

dr-yay ★★ ()
Ответ на: комментарий от dr-yay

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

alozovskoy ★★★★★ ()
Ответ на: комментарий от alozovskoy

общая чтоб никто не путался с правами на каталоги и т.д.

Замени на пачку внешних утилит, синхронизирующих необходимые каталоги, которые должны быть типа-общими. Не делай больше общих учёток. Вообще сдаётся мне, что ты хочешь сделать VCS-репозиторий и разделённые права доступа к нему, но даже не через жопу, а фиг знает как.

x3al ★★★★★ ()
Ответ на: комментарий от alozovskoy

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

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

Deleted ()
Ответ на: комментарий от nanoolinux

Нет, это вообще «личный проект», упрощение некоторых рутинных дейтсвий, там есть общие для большой группы людей скрипты и скрипты, которые должны быть общими для небольшой группы людей.

alozovskoy ★★★★★ ()
Ответ на: комментарий от Deleted

Так вот я хочу сделать решение, «прозрачное» для того, кто будет заводить нового пользователя. Новый пользователь просто потом генерит себе ключ чтоб ходить под общей учеткой, и все это абсолютно не касается «рута».

alozovskoy ★★★★★ ()
Ответ на: комментарий от x3al

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

VCS-репозиторий и разделённые права доступа к нему

Нет, такого мне не требуется.

alozovskoy ★★★★★ ()
Ответ на: комментарий от alozovskoy

вряд ли запомнит

у нового пользователя не окажется доступа в общие каталоги, и тогда ему напомнят сами пользователи

dr-yay ★★ ()
Ответ на: комментарий от dr-yay

Ну как вариант, но тоже лишние телодвижения и может способствовать росту бюрократии.

alozovskoy ★★★★★ ()

ограничение членства в группе прекрасно справляется с этой задачей: KISS

Идея такая: от root или anyhostadmin (теоретически ;) :

создать группу: hostinventory например

задать членство в этой группе тем, кто может иметь доступ в папки secret-service

mkdir /home/hostuser/secret-service

chown -R anyhostadmin:hostinventory /home/hostuser/secret-service

chmod 660 -R /home/hostuser/secret-service

anonymous ()
Ответ на: комментарий от anonymous

Да, это правильное и хорошее решение, но сейчас у меня уже есть «готовый» хост с пользователями, и я хочу найти выход из сложившейся ситуации. Конечно описанный тобой вариант был бы применен, если бы делал я (или будет применен, если я не найду решения)

alozovskoy ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.