User: Password:
|
|
Subscribe / Log in / New account

Doesn't go far enough for file servers

Doesn't go far enough for file servers

Posted Jun 5, 2012 18:40 UTC (Tue) by nybble41 (subscriber, #55106)
In reply to: Doesn't go far enough for file servers by Cyberax
Parent article: User and group mount options for ext filesystems

If you can't see why it's a bad idea for both security and usability to have two different, conflicting sets of permissions for the same data, then I can only say that I'm glad you probably don't have any influence on this issue. Consider the case of restricting write access to a file: you would need to know about, and have write access to, _all_ the directory entries referring to that file, as opposed to just a single inode in the current model.

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.


(Log in to post comments)

Doesn't go far enough for file servers

Posted Jun 5, 2012 20:41 UTC (Tue) by dgm (subscriber, #49227) [Link]

Sometimes it's a GOOD idea to have different sets of permissions. The final permission set is just the union of both, something that can be difficult to express otherwise. It would be possible to create *complimentary* permissions, but not conflicting (they are only conflicting if you think of the bits as restriction flags, not permission flags).

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".

Doesn't go far enough for file servers

Posted Jun 5, 2012 21:24 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

> 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".

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.

Doesn't go far enough for file servers

Posted Jun 5, 2012 21:52 UTC (Tue) by dgm (subscriber, #49227) [Link]

You don't need write permissions, because what you're describing is not very reasonable. Imagine we are talking about copies of the data. Would you expect to have a magic command to wipe out all copies of "your" data? Well, if you're the RIAA you would, but it would be unreasonable.

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.

Doesn't go far enough for file servers

Posted Jun 6, 2012 0:48 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> You don't need write permissions, because what you're describing is not very reasonable. Imagine we are talking about copies of the data. Would you expect to have a magic command to wipe out all copies of "your" data?

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?

Doesn't go far enough for file servers

Posted Jun 6, 2012 9:32 UTC (Wed) by dgm (subscriber, #49227) [Link]

> What issue are you trying to solve by moving permissions to the directory entry?

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.

Doesn't go far enough for file servers

Posted Jun 6, 2012 15:16 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> Basically the same ACLs solve, but using just permission bits.

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.

Doesn't go far enough for file servers

Posted Jun 6, 2012 17:29 UTC (Wed) by dgm (subscriber, #49227) [Link]

> I don't see how requiring multiple directory entries for the same effect is a "more sensible" solution.

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 © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds