I know, bad form and all following up to myself. Everyone keeps
mentioning how bad ACLs are and how they need user-space regulation.
Let me explain what I see, what I believe Windows NT/XP does, and
hopefully we can reach some consensus among those who really know.
Problems with normal Unix permissions:
1) You only have three categories (user/owner, group, world/other).
2) Owner can't offer (transfer) ownership to someone else (NT does this
right by making it belong to the owner until the potential new owner
accepts).
3) Limited number of groups.
4) Only root can add groups
5) Only root can change group ownership of a file
What I see NT doing:
1) Owner can allow read, write, delete, execute to anyone or any group
(this is great, though delete and write might as well be the same thing
I think)
2) NT Kernel + fs dictates rights, not the user-land
3) Non-owner user cannot give rights to anyone else (though, I believe
they can remove rights from themselves, though it has been a LONG time
and I am not sure)
4) Owner can offer transfer of ownership (though this may be dumb in
Linux)
5) No need for groups for small numbers of additional users with rwx
abilities
6) On copy the ACL is reset to the owner only.
7) On move, it copies the ACL (see problems with ACLs below)
Where does user-land fit in:
Right now it fits in with chown. I believe everything else is done in
kernel for permissions now. Why are we blaming everything on user-land
now with more powerful ACLs/permissions? You need a tool that can
request that the kernel do xyz update on the ACL for file abc. The
kernel then says done, you are the owner of the file, or heck no, go
away you aren't the owner even if you have rwx privileges.
Why ACLs are needed:
I know many people who would love to move to Linux for all sorts of
things, but they need ACLs. Sysadmins can't always be running around
chowning things for different groups, adding users to groups, removing
users to groups, removing dead groups, etc. ACLs allows the owner of
the file to do things as they really should be done. ACLs do need at
least a concept of additional users (not owners) of a file. It would be
nice if it would work with groups too, even if root intervention was
still required for creating groups.
Why are ACLs bad:
1) It takes some brains so that you totally don't screw yourself over
with your data... however this still can happen with the current Unix
permissions. It just becomes more complex.
2) More complex kernel code... well every feature does. I believe this
one is worth it.
3) Different file systems have different ACL sets... OK, so what.
User-space just needs to be able to know what they are on each fs, as
does the kernel. I don't really think there needs to be a huge issue,
other than on a move. Copy would reset the ACL to the owner's default
(the new owner, not the original file owner). Move needs to be able to
copy the ACLs with the file. Within the same fs type (even if different
volumes), this should be easy. Between fs types, this may be a problem.
4) New/update user space tools required. All new features do. Heck,
networking needs new versions all the time.
5) Disk/kernel bloat. Make it a compile time option I guess. Those who
need/want can have, those who don't, good too.
Does POSIX ACLs do all this:
I have no clue. I don't know if they are sane or not. I see a proper
ACL definition just extending and working with standard permissions
including the rules of inheritance and priority.
Am I crazy:
I may very well be. I may have no clue what I am talking about.
However, I wrote this because I really don't see all the arguments about
how horrible it is because of user-land.
Can most of the positives be emulated via setuid apps:
Maybe. However, you still are limited to three fields of authorization,
verses the many more of the other. Also, it would require more
user-land updates to do this than to do it with ACLs IMHO.
Thank you for your time and corrections where I am wrong. Please,
direct flames to your /dev/null mine is full :)
Trever Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/