Возможно ли/желательно иметь пользовательскую домашнюю папку?

Question

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

/home 
└── [-rw-rw-r-- daedalus ] daedalus 
    ├── [-rw-rw-r-- root ] do_not_delete_file.cpp 
    ├── [-rw-rw-r-- root ] do_not_delete_file.html 
    ├── [-rw-rw-r-- root ] do_not_delete_file.php 
    ├── [drwxrwxr-x root ] do_not_delete_folder 
    │   ├── [-rw-rw-r-- root ] do_not_delete_file.cpp 
    │   ├── [-rw-rw-r-- root ] do_not_delete_file.html 
    │   └── [-rw-rw-r-- root ] do_not_delete_file.php 
    └── [-rw-rw-r-- daedalus ] index.html 

Но это не удается, потому что пользователь daedalus имеет запись, и, следовательно, удаление, разрешения на их собственный /home/daedalus папка. Таким образом, хотя они не могут изменять, например, do_not_delete_file.php, они всегда могут удалить его, а затем заменить.

но что, если вместо того, чтобы у меня было что-то вроде этого

/home 
└── [-rw-rw-r-- root ] daedalus 
    ├── [-rw-rw-r-- root ] do_not_delete_file.cpp 
    ├── [-rw-rw-r-- root ] do_not_delete_file.html 
    ├── [-rw-rw-r-- root ] do_not_delete_file.php 
    ├── [drwxrwxr-x root ] do_not_delete_folder 
    │   ├── [-rw-rw-r-- root ] do_not_delete_file.cpp 
    │   ├── [-rw-rw-r-- root ] do_not_delete_file.html 
    │   └── [-rw-rw-r-- root ] do_not_delete_file.php 
    ├── [drwxrwxr-x daedalus ] Documents 
    └── [-rw-rw-r-- root ] index.html 

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

EDIT: Причина, по которой я задаю этот вопрос, связана с программированием LAMP. Я создаю серию ВХосты, а именно:

• www.user1.example.com
• www.user2.example.com
• ...
• www.userN.example.com

И я хочу DOCROOT быть установлен на:

• /home/user1
• /home/user2
• ...
• /home/userN

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

Answer 1

Это немного сложно, но вы можете сделать это, используя Sticky Bit.

http://en.wikipedia.org/wiki/Sticky_bit

Ядро Linux игнорирует Липкий бит для каталогов, за исключением. Для каталогов Linux позволяет только суперпользователям и владельцу удалять, переименовывать или отменить связь с файлами. Он не позволяет пользователю, имеющему доступ к файлу, используя групповое разрешение.

Для примера, мой пользователь называется виноград и является членом группы винограда

Чтобы добавить липучки использовать Bit CHMOD:

chmod +t [file] 

Здесь вы можете создать каталог, который имеет пользователь разрешения на использование групп, но принадлежат корню

drwxrwxr-Т 2 корня винограда 4096 2012-04-19 20:49 ул

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

-rwxrwxrwx 1 root root 0 2012-04-19 20:45 test 
-rw-rw-r-- 1 grape grape 0 2012-04-19 20:56 test2 

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

Answer 2

Многие программы - и пользователи - ожидают, что смогут создавать любые файлы, необходимые непосредственно в их домашнем каталоге. Это может быть ~/.xsession-errors, ~/.viminfo, ~/.lesshst, ~/.bash_history или другие, которых я мог пропустить - или что я не запускаюсь, но ваши пользователи работают.

Таким образом, это не будет безболезненным, но вот несколько идей:

• Вы можете приблизиться к тому, что вы хотите, имея домашний каталог, принадлежащий кому-то еще и установить справочника липкий бит - это потребует от пользователя владения файлом или каталогом, прежде чем его можно будет удалить; от unlink(2):

  EPERM or EACCES 
       The directory containing pathname has the sticky bit 
       (S_ISVTX) set and the process's effective UID is 
       neither the UID of the file to be deleted nor that of 
       the directory containing it, and the process is not 
       privileged (Linux: does not have the CAP_FOWNER 
       capability). 
  

  Вы бы должны либо перейти к чрезмерному длины либо setfacl(1) установить списки контроля доступа или дать каждому пользователю свою собственную группу. Без одного из этих двух шагов вы можете случайно предоставить пользователям право изменять данные друг друга.

• Вы можете использовать атрибут chattr(1)i сделать файл неизменны - он не может быть изменен, связаны между собой, или несвязанные, кроме привилегированного процесса. От chattr(1):

  A file with the `i' attribute cannot be modified: it cannot 
  be deleted or renamed, no link can be created to this file 
  and no data can be written to the file. Only the superuser 
  or a process possessing the CAP_LINUX_IMMUTABLE capability 
  can set or clear this attribute. 
  

• Вы можете использовать Монтирование смонтировать файл или каталог в домашней директории пользователя. Это можно сделать, пока пользователь по-прежнему владеет своим домашним каталогом; просто запустите mount -obind /path/to/source /home/daedalus/do_not_delete. Если каталог или файл не принадлежит пользователю, они не могут изменить файл, и они не могут изменить точку монтирования. (Они могут изменить каталоги более высокого уровня, чтобы сделать путь бессмысленно - так это сделать непосредственно в домашний каталог, но не пытайтесь делать это в подкаталог.)

  # mount -obind /etc /tmp/sarnold/mount_point/ 
  # mount -obind /etc/passwd /tmp/sarnold/passwd 
  $ rm mount_point/ 
  rm: cannot remove `mount_point/': Is a directory 
  $ rmdir mount_point/ 
  rmdir: failed to remove `mount_point/': Device or resource busy 
  $ mv mount_point/ blob 
  mv: cannot move `mount_point/' to `blob': Device or resource busy 
  $ rm /tmp/sarnold/passwd 
  rm: remove write-protected regular file `/tmp/sarnold/passwd'? y 
  rm: cannot remove `/tmp/sarnold/passwd': Device or resource busy 
  $ mv /tmp/sarnold/passwd /tmp/sarnold/old_passwd 
  mv: cannot move `/tmp/sarnold/passwd' to `/tmp/sarnold/old_passwd': Device or resource busy 
  

  (я ушел из создавая то есть просто touch или mkdir.)

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

• Вы можете настроить mandatory access control инструмент, как AppArmor, SELinux, TOMOYO или SMACK ограничить привилегии, доступные для пользовательских процессов. (Я являюсь членом команды AppArmor в течение двенадцати лет, в зависимости от того, как используются ваши серверы, это может быть или не быть идеальным для этого использования. Я считаю, что большинство этих систем могут быть настроены так, чтобы делать то, что вы хотите, но так как AppArmor и Tomoyo являются имя на основе, я считаю, что они будут более склонны контролировать доступ к файлам и каталогам, чем SELinux или привкусом, которые этикеток на основе системы.)