[OpenAFS] fs setacl and permissions

[Christof Hanke]

Juha J=C3=A4ykk=C3=A4 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.
>=20
> 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 alte=
r
> 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=20
it, but cannot chown. Ok, there's no "a"-bit in normal filesystems, but=20
even the owner of a directory cannot do everything with its content=20
(saying that for my linux-box).

>=20
> Why is this, anyway? To prevent the administrator of dir1 from
> commandeering its subdirectories? The old trick with implicit rights an=
d
> chown was neat since on AFS there is no need to fear for your quota bei=
ng
> filled by other people giving you files (the most common reason, I thin=
k,
> to disallow giving away files with chown).
I dont't know exactly, but directories don't inherit ACLs, as mentioned=20
above, so they are completely distinct entities. ACL-inheritance could=20
violate security-models. If, by mistake, somebody get "a"-rights on=20
/afs/@cell, he had the whole cell under his control, if the behaviour=20
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 t=
he
> permissions - I assume.=20
>=20
> 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, grou=
ps
> are easier anyway since there are multiple members per group.
>=20
Yes in the situation you described above I would definitely go for groups.

> -Juha
>=20
/Christof