Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Doesn't go far enough for file servers
Posted Jun 5, 2012 0:29 UTC (Tue) by nybble41 (subscriber, #55106)
That would certainly simplify the ACL inheritance situation, but it's the files themselves you want to control access to, not the directory entries. Having different permissions depending on how you access the file seems like a big step backward to me.
"Live" inherited ACLs have obvious issues; the hard-link case is particularly bad. However, "static" inheritance, as with the default POSIX ACL associated with a directory, offers a reasonable compromise. A file receives the default ACL of the directory in which it is created, and retains that ACL (unless separately modified) even if the file is moved or hard-linked into another directory. If inheritance is preferred after a move or directory permission change, the default ACL of the new containing directory can be re-applied as a separate step.
Posted Jun 5, 2012 1:47 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
And it's not quite unlike the current situation - you must have +r access to file's directory to be able to read it (if you obtain the file handle to it by doing path traversal).
Posted Jun 5, 2012 15:30 UTC (Tue) by nybble41 (subscriber, #55106)
The current situation is that you need read permission to a directory to read its directory entries (e.g. with ls), and search (+x) permission to access files and directories under it. The two are orthogonal; you don't need read access just to traverse a directory, and you don't need search permission just to list the contents.
You also need read access to the individual file to access the file's contents, and typically _that_ is what you want to protect. The read and search bits on the directory govern access to the directory (listing and traversing), while the permission bits on the file govern access to the file's contents.
In the common case of one directory entry per file, there is no difference between your proposal and the way the system already works. Each file would still have one set of permissions, just stored in the directory entry rather than the inode. However, in the case of a file hard-linked into multiple directories, a single item (the contents of the file) would have multiple, possibly conflicting, permissions, depending on the directory entry used to access it. I consider that a step backward from the current model of one clear-cut set of permissions per filesystem object.
Posted Jun 5, 2012 17:11 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Personally, I'd simply ban hardlinks completely if it was up to me.
Posted Jun 5, 2012 18:40 UTC (Tue) by nybble41 (subscriber, #55106)
That goes double for the idea of banning hard links, which are actually quite useful and logical given the separation between human-readable names and inodes. In any case, without hard links there is no motive for moving the permission bits to the directory entry, as you suggest, since the mapping between directory entries and inodes would be one-to-one. Only the case with hard-links is interesting in this context.
The filesystem permissions apply to inodes and not directory entries for a reason, and once you replace the limited owner/group/other model with POSIX ACLs, the system works rather well as-is. It's only the Windows-style permission model which has issues relating to inherited ACL.
Posted Jun 5, 2012 20:41 UTC (Tue) by dgm (subscriber, #49227)
In the case of write access, you only need back-pointers (from inode to directory) like btrfs has to trivially get "_all_ the directory entries referring to that file".
Posted Jun 5, 2012 21:24 UTC (Tue) by nybble41 (subscriber, #55106)
You'd still need write access to all those directories to change the permissions stored in the directory entries. That can be a problem if you own the file, but someone else owns some or all of those directories. Alternatively, the system could grant write access to directory entries based on the ownership of the target inode rather than the ownership of the directory. Both methods are counter-intuitive.
Regular POSIX ACLs can already express the union of two sets of permissions. There is no need to vary the permissions based on the path used to access the file.
Posted Jun 5, 2012 21:52 UTC (Tue) by dgm (subscriber, #49227)
If you have write permissions, you can wipe the file contents clean and destroy your links. Others will still be able to open the file, but the data would not be there anymore. If you have read permissions, then all you can do is remove your link.
Posted Jun 6, 2012 0:48 UTC (Wed) by nybble41 (subscriber, #55106)
Obviously not. I'm not concerned with copies, just the original, mutable file. If the file is static then the only function of hard links is to save space. As you say, each user might as well have their own copy of the file, and I wouldn't expect to be able to control that copy after granting access.
> If you have write permissions, you can wipe the file contents clean and destroy your links. Others will still be able to open the file, but the data would not be there anymore.
If the contents of the file are dynamic rather than static, then destroying the links removes not just write access, but also read-only access to any future updates. Let's say that there is a file which I own, and which I'm sharing with several other users. Some of these users should be able to write to the file, while others only get read access. For whatever reason (perhaps they're using chroots for sandboxing), some or all of the users have their own hard links to this file rather than using a single path.
With per-inode permissions, to revoke another user's write access while leaving them read access to the shared file, including any future updates, all I have to do is update the ACL on the file. If I were to destroy my link and start over, on the other hand, I would also have to recreate everyone else's links using the new permissions so that we are once again sharing the same file.
Frankly, I don't see any benefits to this change. One ACL per filesystem object has served us well for a long time. The original problem in this thread was with inherited ACLs and multiple parent directories, a problem with doesn't apply to POSIX ACLs, which have defaults but not inheritance. What issue are you trying to solve by moving permissions to the directory entry?
Posted Jun 6, 2012 9:32 UTC (Wed) by dgm (subscriber, #49227)
Basically the same ACLs solve, but using just permission bits. I personally find them much more sensible, and think this is something that could have been better, had Unix been designed this way instead.
Now it's too late, of course.
Posted Jun 6, 2012 15:16 UTC (Wed) by nybble41 (subscriber, #55106)
But POSIX ACLs are basically permission bits, just without the "one user plus one group" limitation. They still govern read, write, and execute/search permissions for specific users and groups and "others". I don't see how requiring multiple directory entries for the same effect is a "more sensible" solution.
That the UNIX permissions model could have been better--I have no argument with you there. We could have used POSIX-style ACLs from the beginning, and skipped the restrictive user/group/other model entirely.
Posted Jun 6, 2012 17:29 UTC (Wed) by dgm (subscriber, #49227)
One word explanation: ls
Multiple word explanation: It's a question of simplicity, I suppose. This way you avoid introducing more concepts and tools. Notice just how simple it is to say "every link can have different permissions". Compare that to the simplest explanation of POSIX ACLs.
Additionally, you don't need to modify existing tools, and hardly add any new ones. The only one you may want to add is something that gives back the list of aliases (links) to a file.
In return for that simplicity you have to give up on the expectation of absolute ownership. You no longer can revoke permissions on other's links, but you can always recreate a file.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds