Juha Jäykkä schrieb:
as a member of system:adminstrators, do
mkdir /afs/cell/dir
mkdir /afs/cell/dir/dir2
fs setacl /afs/cell/dir user all
as user, do
fs setacl /afs/cell/dir/dir2 anyone anything
to get
fs: You don't have the required access rights on ...
This is the expected behaviour, ACLs are not inherited.
Is it? I definitely didn't expect it. ACLs are not inherited, but since
user here has full access to dir, why should user not be able to alter
things within the dir? If user has full administrative rights to dir,
then user should be able to do whatever one wants with dir/dir2. I
thought directories are nothing more but "table of contents" so if user
has permission alter the table of contents ("a"), why can user not alter
the table of contents (whether he can access a certain object mentioned
in the ToC)?
It is a bit similar in UNIX, but not quite.
If you have a file belonging to root in a user-dir, the user may delete
it, but cannot chown. Ok, there's no "a"-bit in normal filesystems, but
even the owner of a directory cannot do everything with its content
(saying that for my linux-box).
Why is this, anyway? To prevent the administrator of dir1 from
commandeering its subdirectories? The old trick with implicit rights and
chown was neat since on AFS there is no need to fear for your quota being
filled by other people giving you files (the most common reason, I think,
to disallow giving away files with chown).
I dont't know exactly, but directories don't inherit ACLs, as mentioned
above, so they are completely distinct entities. ACL-inheritance could
violate security-models. If, by mistake, somebody get "a"-rights on
/afs/@cell, he had the whole cell under his control, if the behaviour
would be as you expected. I guess this is not wanted.
Luckily it seems as if directory trees like the above are not very
common. We have, however some trees, where dir1 is owned by user1,
dir1/dir2a by user1, dir1/dir2b by user2 and dir1/dir2b/dir3 by user3.
These directories change owners frequently, but luckily for us, user1
always stays around for at least a year at a time so user1 can handle the
permissions - I assume.
Perhaps the way to go is groups, although this situation would dictate
groups with only a single member, but at least memberships can be given
and taken easily without admin interference. All other situations, groups
are easier anyway since there are multiple members per group.
Yes in the situation you described above I would definitely go for groups.
-Juha
/Christof
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
