It's counterintuitive that the owner can have <i>less</i> rights than the others. Honestly, I've never seen it put in practice in any real-world file system.<p>Incidentally, this is also not very efficient: UNIX permissions as they are today require 9 bits, namely rwx for owner, rwx for group, and rwx for others. But in an alternative universe where owner's rights win over group's rights which win over others' rights, permissions could be coded in just 6 bits: 2 to express who can read, 2 for who can write, and 2 for who can execute. Each set of 2 bits would be interpreted this way: 00=nobody, 01=only owner, 10=group or owner, 11=everybody.
I attended a Tanenbaum lecture once where he talked about how silly it was that nothing happens if permissions are reduced for a file while some other user/process has an open handle to it, and this is something Linux doesn't care to handle and MINIX does (or perhaps just that a kernel/filesystem should handle it, and few do -- I don't recall exactly). Surely an edge case (logging? what else? I never keep files open for too long), but I thought it was an interesting one.<p>You can test this in Bash: userA does cat>/tmp/newfile (assuming a chmod or relaxed umask so /tmp/newfile is created with permissions 0664), userA types in lines of text every few seconds, userB does tail -f /tmp/newfile and watches lines appear, then userA does chmod 600 /tmp/newfile, but userB can continue to tail -f /tmp/newfile and watch lines appear.
The nicer things are suid a guid.<p>suid is to run things as another user without passwords. Mostly used for root access today and ignored for anything else. I personally think that's a missed oportunity when they added the unshare/namespace/capdrop stuff... would have been so nice if the interface to containers was a freaking simple 'suid as this lowly user' for a userland api. anyway.<p>and guid ON DIRECTORIES, are so that users can save files in a groups that then others can also update. So you can have `/srv/http/htdocs userA webmasters -rwxswx---`<p>then there's umask which may help or get in the way. and getfacl et al.<p>overall it's a mess that covers many usecases after you've been initiated.
Interesting, I was just diving into the permission system today. I was wondering if it was possible to delegate administration of a directory, e.g. give permission to some non-root user to delete files created by others in that directory.<p>Turns out it doesn't seem possible. Even if you use ACLs, whatever default ACL you set can just be removed from sub-directories by their respective owners. This seems like a big blind spot, unless I just missed something; all those groups, access lists, bits, and I can't even do that?
I've been wondering about this for awhile. Do we really need multiple users for desktop unix? I get that you want some division between system and user, to protect the user against themselves. And read-only files are similarly useful, if only because some devices are read-only. But do we really need user/group/other permissions for desktop unix? and all the complexity of groups, and euid, etc.<p>Edit: not sure why I'm getting downvoted. Is it that offensive to question orthodoxy?