0

我之前曾问过有关防止用户通过执行以下操作来删除其主目录中的某些关键文件/文件夹的问题：

/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 编程有关。我正在创建一系列 VHost，即：

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

我希望将 DocRoot 设置为：

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

但是，我正在努力为个人用户授予太多/太少的自由。在最简单的情况下，我可能想要一个do_not_delete_folder用户可以访问但不能修改/删除的。

4

2 回答 2

3

这有点棘手，但您可以使用 Sticky Bit 来做到这一点。

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

Linux 内核会忽略除目录之外的 Sticky Bit。对于目录，linux 只允许超级用户和所有者删除、重命名或取消链接文件。它不允许有权访问文件的用户使用组权限。

例如，我的用户名为葡萄并且是葡萄组的成员

要添加粘性位，请使用 chmod：

chmod +t [file]

在这里，您可以创建一个用户有权使用组但归根用户所有的目录

drwxrwxr-T 2 根葡萄 4096 2012-04-19 20:49 st

在这种情况下，用户仍然可以在 st 中创建/删除自己的文件，但不能删除 root 的文件，即使用户具有写权限：

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

我仍然可以读取/写入这两个文件，但只有我拥有的文件可以删除/移动

于 2012-04-20T01:00:29.137 回答
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

    （我没有创建挂载点；这只是一个简单的touchor mkdir。）

    当然，绑定安装在每次重新启动时都会消失。您可能需要正确使用pam_exec(8)或配置您的fstab(5)以在每次登录或引导时重新创建绑定挂载。

  • 您可以配置强制访问控制工具，例如AppArmor、SELinux、TOMOYO或SMACK来限制用户进程可用的权限。（我已经成为 AppArmor 团队的成员 12 年了；根据您的服务器的使用方式，它可能适合也可能不适合这种用途。我相信这些系统中的大多数都可以配置为执行您想要的操作，但由于 AppArmor 和 TOMOYO 是基于名称的，我相信它们比 SELinux 或 SMACK（它们是基于标签的系统）更有可能控制对文件和目录的访问。）

于 2012-04-20T01:09:14.537 回答