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

А в чем проблема? Сделай там каталог под другим юзером (например, 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 разрешить запускать оболочку от имени виртуального юзера.

Если непустая, удалить не сможет (нужно сначала удалить всё, что внутри, а для этого нужно прочитать).

Если непустая, удалить не сможет

Переименовать, переместить - этого хватит.

А, да, точно.

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

chattr +i и не сможет

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

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

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

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

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

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

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

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

Вы вебом занимантесь, да?

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

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

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

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

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

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

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

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

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

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

ограничение членства в группе прекрасно справляется с этой задачей: 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

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