ユーザにホームフォルダを所有させることはできませんか？

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アクションで可能であると仮定していますが、プログラムは自然に彼らは、ライトを持っていると仮定したときに、それは多くの多くの問題につながるとしていますホームディレクトリへのアクセス許可？これが悪い考えであれば、これに取り組む方法について他の提案を得ることができますか？

編集：私はこの質問をLAMPプログラミングと関係があると言います。私はつまり、バーチャルホストのシリーズを作成しています：

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

そして、私はドキュメントルートをに設定したい：

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

しかし、私は、個々のユーザーにすぎ/小さすぎるの自由を認めるに苦しんでいます。最も単純なケースでは、ユーザがアクセスできても変更/削除できないdo_not_delete_folderが必要な場合があります。

Answer 1

これはややこしいことですが、スティッキービットを使用してこれを行うことができます。

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

Linuxカーネルは、ディレクトリ以外のスティッキービットを無視します。ディレクトリの場合、linuxはスーパーユーザと所有者だけがファイルを削除、名前変更、またはリンク解除することができます。グループ権限を使用してファイルにアクセスできるユーザーには許可されません。

は、例えば、私のユーザーは、ブドウの名前と

スティッキービットの使用はchmod追加するにはブドウのグループのメンバーであるされています。ここでは

chmod +t [file] 

を、ユーザーが持っているディレクトリを作成することができますグループを使用する権限が、rootが所有

drwxrwxr-T 2ルートブドウ4096 2012-04-19午後8時49 ST

ユーザが書き込み権限を持っている場合でも、まだSTで自分のファイルを作成/削除することができますが、ルートのファイルを削除することはできません。このような状況で：

-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)のいずれかで、過剰な長さに行く必要があるだろう。この2つの手順のいずれかがないと、間違って互いのデータを変更する権限をユーザーに付与する可能性があります。それは、修正リンク、またはリンクされていない、特権プロセスによって除くことができない -

• あなたはファイル不変を作るために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)を正しく設定して、すべてのログインまたはブート時にバインドマウントを再作成する必要があります。あなたはユーザープロセスに利用できる権限を制限するなどAppArmor、SELinux、TOMOYO、またはSMACKなどmandatory access controlツールを設定でき

• 。 （私は12年間AppArmorチームに所属していましたが、サーバーの使用状況によっては、このようなシステムには理想的ではないかもしれませんが、しかし、AppArmorのとTOMOYOは名前ベースているので、私は彼らがラベルベースシステムであり、SELinuxのかSMACKよりもファイルやディレクトリへのアクセスを制御する可能性が高いだろうと信じています。）