我有一个目录,其中包含许多用户之间共享的数据。对目录及其下任何内容的访问将由目录的组控制,该组将添加到有问题的用户中。这样,我创建了文件夹“粘性组”chmod g+s
集。该目录将包含带有目录和文件的树形结构,文件总数可能为几百万。文件将很小,我预计不会超过50MB。
我的问题是文件或目录的所有者仍然是创建它的用户。因此,即使我应该从访问组中删除该用户,也不会完全删除其访问权限。
所以:
我还有其他选择无法确保所有文件和子目录具有相同的所有者吗?
我希望我可以使用cron-job来定期浏览整个目录,但这使我觉得效率低下,因为它本质上是一次PR文件命令。
我找到了一个使用INotify的示例,但由于需要编写脚本,因此使我感到高维护。
我还无法弄清楚ACL是否可以帮助我进行强制所有权。
有没有更聪明的方法可以做到这一点?
我想要的是拥有一个可以通过向用户添加组来共享的目录。在此目录中创建的任何内容都将从其父级继承许可权方案。如果有比我尝试的方法更好的方法,那么我无所不能。
“自动”设置默认所有者将需要一个setuid
类似的目录setgid
。但是,尽管可以在FreeBSD上配置它,但是其他UNIX&Linux系统只需忽略即可u+s
。但是,根据您的情况,可能还有另一种解决方案。
我想要的是拥有一个可以通过向用户添加组来共享的目录。在此目录中创建的任何内容都将从其父级继承许可权方案。如果有比我尝试的方法更好的方法,那么我无所不能。
因此,基本上,从我的角度来看,您想使用组机制来控制对目录的访问。但是,这不需要您限制整个目录结构中的权限。实际上,目录--x
执行位可能正是您所需要的。让我给你举个例子。假如说...
group_dir
目录的组是ourgroup
。ourgroup
群组中的人可以访问group_dir
。user1
并user2
属于ourgroup
。...考虑以下设置:
drwxrws--- root:ourgroup |- group_dir/
drwxr-sr-x user1:ourgroup |---- group_dir/user1_submission/
drwxr-sr-x user2:ourgroup |---- group_dir/user2_submission/
-rw-r--r-- user2:ourgroup |-------- group_dir/user2_submission/README
在这里,我们假设每个项目都是由其所有者创建的。
现在,在此设置中:
ourgroup
。小组中的任何人都可以在内部任何地方group_dir
(但不能更深入)创建,移动,删除文件。ourgroup
将在处被阻止group_dir
,因此将无法操纵其中的任何内容。例如,user3
(不是的成员ourgroup
)无法读取group_dir/user2_submission/README
(即使他具有r--
文件本身的权限)。但是,这种情况下存在一个小问题:由于典型的umask,用户创建的项目无法被组中的其他成员操纵。这是ACL的来源。通过设置默认权限,即使umask值不变,您也可以确保一切都很好:
$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/
该调用设置:
rw(x)
所有者的默认权限。rw(x)
组的默认权限。group_dir
无论如何都无法访问,因此他们下面的权限并不重要。现在,如果我将项目创建为user2
:
$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw---- user2:ourgroup group_dir/user2_submission/AUTHORS
有了此ACL,我们可以尝试重建以前的结构:
drwxrws---+ root:ourgroup |- group_dir/
drwxrws---+ user1:ourgroup |---- group_dir/user1_submission/
drwxrws---+ user2:ourgroup |---- group_dir/user2_submission/
-rw-rw----+ user2:ourgroup |-------- group_dir/user2_submission/README
同样,每个项目都是由其所有者创建的。
此外,如果您想为使用该目录的用户提供更多的功能/安全性,则可能需要考虑一些便利性。例如,这将防止user1
删除user2_submission
(因为他具有的-w-
许可group_dir
):
$ chmod +t group_dir/
现在,如果user1
尝试删除user2
的目录,他将得到一个可爱的Operation not permitted
。但是请注意,尽管这样做可以防止修改中的目录结构group_dir
,但仍可以访问其下面的文件和目录:
user1@host $ rm -r user2_submission
Operation not permitted
user1@host $ > user2_submission/README
user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)
要考虑的另一件事是,我们使用的ACL设置了默认权限。因此,项目所有者可以更改与之关联的权限。例如,user2
可以完美运行...
$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R
...因此,他的完整提交目录对小组中的任何人都不可用。
但是,由于您最初愿意将全部rws
访问权限授予该组中的任何人,所以我假设您信任这些用户,并且不会期望他们进行过多的恶意操作。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句