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

Doesn't go far enough for file servers

Doesn't go far enough for file servers

Posted May 17, 2012 5:53 UTC (Thu) by ringerc (subscriber, #3071)
In reply to: This patch is even more useful for data servers than for removable media! by martinfick
Parent article: User and group mount options for ext filesystems

I strongly agree with this. I have volumes on my file servers where I very strongly wish I could disable POSIX permissions entirely, replacing them with an inherited ACL from a file system root or subdirectory root.

I want to be able to say "Absolutely all files within this tree must always have the permissions <x>, don't make me waste my time with badly behaved programs that set stupid umasks, idiotic network access clients, etc. Just MAKE IT SO."

The only issue I see with this patch is that it's done at the file system level, and IMO this is something that'd be useful for subtrees within a file system too.

I hate to say it, but what I want is to turn off UNIX-style permissions for some directory trees and have Windows-style inherited ACLs instead. Right now I can have the ACLs, but the permissions triplets always take priority, so some stupid @#$#@W app that sets mode 0700 every directory it creates (I'm looking at you, Thunderbird) still breaks access for everyone else. What I want is for the FS to completely ignore permissions within those trees or force them to a specified value on file/directory creation.


(Log in to post comments)

Doesn't go far enough for file servers

Posted May 18, 2012 15:00 UTC (Fri) by jackb (guest, #41909) [Link]

I strongly agree with this. I have volumes on my file servers where I very strongly wish I could disable POSIX permissions entirely, replacing them with an inherited ACL from a file system root or subdirectory root. I want to be able to say "Absolutely all files within this tree must always have the permissions <x>, don't make me waste my time with badly behaved programs that set stupid umasks, idiotic network access clients, etc. Just MAKE IT SO."
I believe the only way to get what you want is to use Samba and CIFS. It can't be done with local filesystems or NFS.

Doesn't go far enough for file servers

Posted Jun 3, 2012 6:03 UTC (Sun) by quotemstr (subscriber, #45331) [Link]

Windows ACLs are a mess too --- they're attached to files (think "inodes"), not directory entries. If you have a file foo/bar.txt and bar.txt has dutifully inherited its ACL from foo on creation, then if you move foo/bar.txt to qux/bar.txt, bar.txt *retains its old ACL*. Some tools, like Explorer, will reset file ACL on move, but this work is done at the UI-tool level, not the OS level.

Also, Windows supports hard links. Imagine that instead of moving foo/bar.txt to qux/bar.txt, we added qux/bar.txt as a hard link. Which inherited ACL does bar.txt have? It turns out that whichever parent directory modifies its ACL last, wins. (This flaw applies to all ACL inheritance schemes.)

Honestly, I prefer old-fashioned Unix permissions to ACL inheritance. Permissions bits are a lot less confusing and combined with path traversal checking (i.e., in order to read foo/bar.txt, you need execute permission on foo and read permission on bar.txt), it's actually rather flexible.

Doesn't go far enough for file servers

Posted Jun 4, 2012 4:40 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I don't think the behavior you described is unreasonable, I'm not sure what "better" behavior would be in that situation. In any event there are far far far more people who prefer ACLs and find them better for practical use than Unix permissions bits for shared file management.

Doesn't go far enough for file servers

Posted Jun 4, 2012 5:09 UTC (Mon) by dlang (subscriber, #313) [Link]

please show me any system that allows both unix permissions and ACLs where more people use the ACLs than the unix permissions.

the fact that more people use windows ACLs is because more people use windows due to the apps that it supports, not because they prefer the ACL model.

Doesn't go far enough for file servers

Posted Jun 4, 2012 13:16 UTC (Mon) by nix (subscriber, #2304) [Link]

The problem with the system quotemstr describes is that it is path-dependent: if you look at the inherited set of ACLs attached to some directory, you cannot use it to determine what the properties of files underneath are likely to be unless you know the history of those files (which is not recorded anywhere). Worse yet, files *outside* that directory may have been affected by its ACL, as long as they were at one point within that directory -- or, rather, they would have been affected by whatever ACL it had at that point (it may have been changed, but the moved-out file's ACL would not have changed).

Thus, you cannot look at the limited set of ACLs attached directly to files and their inherited permission set to figure out what their actual ACLs are: you have to look at the whole, huge, set for every single file, because the inheritance is a thin layer atop that implementation, and the underlying layer shows through (though that it shows through on non-GUI file moves is particularly shoddy).

Doesn't go far enough for file servers

Posted Jun 4, 2012 13:33 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

You just need to know parent directory's ACL and file's ACL. No need for anything more significant.

Windows ACLs are a PITA - they're so complicated that one needs a PhD in aclology too understand them completely. But they actually allow several very useful use-cases that depend on ACL inheritance.

In general, I like Unix permission bits for static structures (like /usr or /var filesystems) but I absolutely hate them for shared dynamic directories.

Doesn't go far enough for file servers

Posted Jun 4, 2012 18:12 UTC (Mon) by nix (subscriber, #2304) [Link]

You just need to know parent directory's ACL and file's ACL. No need for anything more significant.
As I pointed out, for Windows ACLs, that is not true: you need to know the mv history of the file and (since files might have been moved out of and then back into directories with inherited ACLs) the ACL history of all directories it has moved into over its lifetime as well. None of this information is recorded anywhere.

Doesn't go far enough for file servers

Posted Jun 4, 2012 18:42 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Why? Moving a file simply changes its ACLs. No need to track them for the whole lifetime of the file.

Doesn't go far enough for file servers

Posted Jun 6, 2012 17:33 UTC (Wed) by nix (subscriber, #2304) [Link]

As was pointed out a few posts up, moving a file does *not* change its ACLs unless you do the move *from the GUI*. A command-line move leaves the ACLs unchanged, and does not respect inherited ACLs (i.e. inherited ACLs are not really part of the permission system but are a hack implemented at the GUI level). Thus the problems I mentioned.

Doesn't go far enough for file servers

Posted Jun 4, 2012 23:43 UTC (Mon) by quotemstr (subscriber, #45331) [Link]

The right thing to do would have been to attach ACLs to *directory entries*, not to files themselves. When you do that, everything automatically just works.

Doesn't go far enough for file servers

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

> The right thing to do would have been to attach ACLs to *directory entries*, not to files themselves.

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.

Doesn't go far enough for file servers

Posted Jun 5, 2012 1:47 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

>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.
Why? It's totally natural and logical.

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

Doesn't go far enough for file servers

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

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

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.

Doesn't go far enough for file servers

Posted Jun 5, 2012 17:11 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

>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.
Why is it bad?

Personally, I'd simply ban hardlinks completely if it was up to me.

Doesn't go far enough for file servers

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

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.

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