LWN: Comments on "Common needs for Samba and NFS"

Common needs for Samba and NFS

pgoetz — Mon, 03 Jun 2019 11:27:01 +0000

> Well, they should just remain on Windows then. Why should Linux get all the braindeadness of other OSes for the sake of a handful of mastodon companies?

I work with scientists at a university and have a real need for various RichACL features (so not just of importance to a handful of mastodon companies).

Common needs for Samba and NFS

bfields — Wed, 29 May 2019 15:10:25 +0000

Again, the "automatic" inheritance isn't really automatic. It's something much simpler; see above for explanation.

And, anyway, we're not really looking for a clever way to make automatic inheritance work, we're just trying to provide a little Windows compatibility. And the Windows folks (quite sensibly, in my opinion) chose to do this much simpler thing.

Common needs for Samba and NFS

Wol — Wed, 29 May 2019 00:03:38 +0000

> Exactly that. Inherited ACLs are basically a bad idea, they are impossible to implement efficiently.

Simple, reasonably efficient mechanism ...

First of all, don't "mix and match" ACLs - the rule should be "the first hit is the only hit". Which yes it means a not particularly efficient traversal up the path looking for an ACL, but you don't get things like wrongly updated trees because the tree isn't updated. Update the root ACL, all new accesses will find it straight away. How fast is an upwards traversal reading the ".." entry in the directory?

Everything I find a pain in Windows ACLs and others is all down to rules about how conflicting ACLs interact. Pr1me ACLs just worked on the basis of "the first hit applies". SOOO much simpler.

Cheers,
Wol

Common needs for Samba and NFS

Cyberax — Tue, 28 May 2019 01:13:18 +0000

> Isn't this the same argument being made above about RichACLs..? Namely, they exist in large Enterprises so they should be supported.
No. POSIX ACLs are already supported in Linux, with all of their mis-features. Adding more crap for the sake of a couple of large enterprises is not a good idea.

These enterprises can very well carry these patches in a custom kernel build.

Common needs for Samba and NFS

ssmith32 — Mon, 27 May 2019 23:12:15 +0000

> but they're here so we have to live with them.

Isn't this the same argument being made above about RichACLs..? Namely, they exist in large Enterprises so they should be supported.

I suppose it all depends on where you "live".

Granted, I mostly "live" on cloud providers & home machines nowadays, so both posix & whatever windows is doing is fairly irrelevant.

It seems like, wherever I go, no one is happy with their auth scheme, but it's always better than whatever the other thing is. .. ¯\_(ツ)_/¯

Common needs for Samba and NFS

nix — Mon, 27 May 2019 17:48:09 +0000

Filesystem people hear "automatic inheritance" and immediately jump to the assumption that you're trying to do something much more sophisticated, and start worrying about all the corner cases.

Guilty as charged, though I haven't been a filesystem developer for a long time :)

Common needs for Samba and NFS

bfields — Sun, 26 May 2019 20:17:31 +0000

"But doesn't that mean that there might be an arbitrarily long lag between your changing a root ACL and having the change propagate to children?"

Sure. Just as for chmod -R. You'd run setrichacl with a --recursive option, and you'd wait while setrichacl traversed the tree fixing things up.

It's a bit annoying, but it's a simple idea and I think people understand it. They know it'll take a while on a big tree, they know that the job's going to be left half-done if they interrupt it partway through, etc.

(Disclaimer: I don't remember whether Andreas actually got around to writing that UI, or exactly how he did it if so. And I don't know the Windows UI. But my understanding is that, again, it doesn't try to hide the fact that there's a recursive operation when you ask it to propagate a new inherited ACL.)

This is a really simple low-tech feature. "Automatic inheritance" was probably a bad name for it, at least if you want to sell it to filesystem developers. Filesystem people hear "automatic inheritance" and immediately jump to the assumption that you're trying to do something much more sophisticated, and start worrying about all the corner cases.

Common needs for Samba and NFS

zdzichu — Sun, 26 May 2019 09:09:18 +0000

“SMB” could both Small/Medium Business and Server Message Block (protocol). Mid-size factory is neither. Samba is a server for later.

Common needs for Samba and NFS

cpitrat — Sun, 26 May 2019 06:58:43 +0000

Exactly that. I know nothing about the topic but the discussion I see looks like:
- RichACLs are bad
- why?
- because I don't like them
- but why?
- because they are crap
- but why?
...

They are complex? Well, I don't know any area which is not / does not require complexity when you look carefully at it.

They are more complex than POSIX ACLs? Well, I'd expect that, the main complain about POSIX ACLs is that they are too simple. Of course, in theory you can do whatever you want with them. In practice, having a different group per file is not manageable. I don't know what RichACL supports but it seems to me that being able to have multiple groups and users allowed a certain access to a file is a minimum to make users life easier.

Common needs for Samba and NFS

cpitrat — Sun, 26 May 2019 06:48:24 +0000

"I've worked with dozens of SMBs in various areas and not once have I seen SMB. "
"The only place I've seen SMB ..."

Wait, what?

Common needs for Samba and NFS

nix — Thu, 23 May 2019 12:44:55 +0000

So all the "automatic inheritance" stuff does is add flags that userspace can use to determine which ACEs in a given ACL were inherited from somewhere else, so they can (if they want) use that information to decide how to modify the ACL while doing a recursive traversal.

But doesn't that mean that there might be an arbitrarily long lag between your changing a root ACL and having the change propagate to children? That sort of thing seems... rather suboptimal for something with security implications (like permissions), though I suppose you could have synchronization mechanisms so you could wait until the userspace fixer-upper had propagated the change. (Heck, it's even suboptimal for something *without* security implications -- can you imagine if rename() worked that way? rename(a, b) and now we have to wait for a while before a vanishes and maybe longer before b appears?)

Unlike Cyberax, I like the idea of this -- it just seems... really hard to do well.

Common needs for Samba and NFS

HelloWorld — Thu, 23 May 2019 08:06:16 +0000

So what do you need SMB for then?

Common needs for Samba and NFS

Wol — Thu, 23 May 2019 03:35:48 +0000

> the presence of more complex ACLs with deny entries (one of the key differences between RichACL and the draft POSIX ACLs that Linux implements) is going to be hard to avoid, especially for systems accessed over the network.

Please NO NO NO.

Deny ACLs are something I've never understood. Less complexity == better security.

Just don't mix and match user and group ACLs. If the user ACL over-rides the group ACL, why do you need a deny? If someone has permissions via one group, and denies via another, surely there's something wrong somewhere? And, looked at logically, why should deny over-ride permit?

Cheers,
Wol

Common needs for Samba and NFS

neilbrown — Thu, 23 May 2019 00:54:05 +0000

> And while we're at it, how would you design "POSIX" ACLs differently?

I would say that the whole idea of per-file permissions is fundamentally broken and not what people really want, and I wouldn't let "POSIX" ACLs get past "draft" stage - I would nip it in the bud and "just say no".

There are two classes of permissions that cover most files: 0600 and 0644.
(Having "execute" as a permission bit is a cheap-hack and should be deprecated. Your $PATH defines which files are to be treated as executable, not the permission bits).
Files that today have mode 0600 should appear in /home *only* for the owner. Other users shouldn't be able to see them.
Files that today have mode 0644 can appear in global namespace in a read-only part of the tree, and appear writable in /home/shared for the owner.

The next most common scenario is a group that wants shared access to files. People in group "foo" would see "/group/foo" as a read-write mount point. People not in group "foo" wouldn't see this mount point.

Note that this removes the current awkwardness with user and group quotas. The quota doesn't apply to a "user" or a "group", but to a fileset, which might be /home or might be /group/foo.

If you want any permissions more subtle than that, you have a daemon that mediates all accesses. In some cases this might be a database server with it's own arbitrarily complex permission scheme (which might have field granularity within records). In other cases it might be a more generic file server which uses access controls similar to those that Apache supports in .htaccess files, and which only allows whole-file reads and writes.

ACLs? Just Say NO!

Common needs for Samba and NFS

jra — Wed, 22 May 2019 18:22:05 +0000

POSIX ACLS have inheritance on directory ACLS already. bfields is correct, "automatic" inheritance only means propagating some bits to a child object, which is never changed by the kernel after creation, via rename or otherwise.

Only userspace tools change "automatic" inheritance bits on modification, not the kernel. So the comment about filesystems being left in an inconsistent state on rename makes no sense whatsoever.

I'm starting to understand that the objections here are coming from the fact the objectors don't actually understand RichACLs *at all*, or understand what is required.

Common needs for Samba and NFS

Cyberax — Wed, 22 May 2019 18:07:37 +0000

Exactly that. Inherited ACLs are basically a bad idea, they are impossible to implement efficiently.

And a formerly fast atomic rename operations can take many minutes, and a crash in the middle of a re-ACL-ing can leave them in an indeterminate state.

Common needs for Samba and NFS

bfields — Wed, 22 May 2019 16:18:44 +0000

"The implementation is probably painful to do in an efficient fashion."

If Cyberax is thinking about the automatic inheritance stuff, that's described here: https://tools.ietf.org/html/rfc5661#section-6.4.3.2.

It's not really "automatic". It just provides a few extra flags that userspace could use to do a sort of inherited-ACL equivalent to chmod -R.

Basically the problem is that somebody creates a new directory, sets an inheritable ACL on the root, populates it, then realizes a month later, oops, we should have given the "sales" group read access. And they'd like to not only fix the inheritable ACL on the root, but also have the change propagate to the whole tree. And, yes, people that implement filesystems tend to run away screaming from that problem.

The easier solution is to teach user utilities to do the recursive traversal and fix up the tree. Stuff like "chmod -R" already does that.

But, one annoyance is that in the intervening month further ACLs may have been set on subtrees, and you may not want to clobber all those.

So all the "automatic inheritance" stuff does is add flags that userspace can use to determine which ACEs in a given ACL were inherited from somewhere else, so they can (if they want) use that information to decide how to modify the ACL while doing a recursive traversal.

Common needs for Samba and NFS

nix — Tue, 21 May 2019 23:14:12 +0000

The implementation is probably painful to do in an efficient fashion. I can hear this eerie sound which I think is Al Viro screaming :)

Common needs for Samba and NFS

bfields — Fri, 17 May 2019 13:23:50 +0000

The main differences are:

- identification of users and groups by UIDs and GIDs vs. SIDs: not sure if we can do much about this, and in any case it seems like a separate issue.
- support for mode bits: we could simplify richacls if we just ignored mode bits, but that didn't seem like a good idea.

In the end, I trust the Samba developers' judgement that richacls would solve a major problem for them.

Common needs for Samba and NFS

jra — Thu, 16 May 2019 21:40:32 +0000

They're close enough that the minor differences can mostly be ignored by client apps (or hidden by server code). They would be *massively* useful for Windows -> Samba data storage migrations, witness all the Samba Team members in this thread asking for them.

Common needs for Samba and NFS

neilbrown — Thu, 16 May 2019 20:48:47 +0000

Do RichACLs map PERFECTLY to Windows ACLs?
If they do, then I can see a case being made for them.
If not, then I think they are best avoided.

Common needs for Samba and NFS

bfields — Thu, 16 May 2019 16:45:53 +0000

I'm not sure what you mean, or what design problem you're solving.

Common needs for Samba and NFS

Cyberax — Thu, 16 May 2019 16:03:50 +0000

I would personally just extend the user and group bit to multiple entries.

Common needs for Samba and NFS

bfields — Thu, 16 May 2019 13:55:15 +0000

And while we're at it, how would you design "POSIX" ACLs differently?

Common needs for Samba and NFS

bfields — Thu, 16 May 2019 13:52:48 +0000

What don't you like about inheritance?

Common needs for Samba and NFS

smurf — Thu, 16 May 2019 07:34:49 +0000

Totally different use cases. This is not about sharing PDFs between co-workers, or storing your movies. Nobody needs O_DENYREAD or -WRITE for that.

Common needs for Samba and NFS

Cyberax — Thu, 16 May 2019 02:10:24 +0000

For real SMBs? Dropbox, Google Drive, Microsoft CloudDrive etc. I've worked with dozens of SMBs in various areas and not once have I seen SMB. The web-based solutions do work slower than SMB/NFS but at the same time they are reliable and work from anywhere.

The only place I've seen SMB was a mid-size factory that was using it for industrial automation.

Common needs for Samba and NFS

areilly — Thu, 16 May 2019 02:05:21 +0000

As opposed to what alternative for networked file storage? Samba is essentially the only game in town, now that macOS is a SMB client too.

If your answer is some sort of WebDav HTTP-based synchronization thing, then sure, those exist, but they all work orders of magnitude more slowly and generally worse than either SMB or NFS.

Common needs for Samba and NFS

Cyberax — Thu, 16 May 2019 01:18:42 +0000

These kinds of "enterprise" storage basically are almost never used in small businesses.

Common needs for Samba and NFS

rahvin — Wed, 15 May 2019 23:57:13 +0000

The more people move their windows storage to Samba and Linux the better the world will be (at the very least my servers will stop getting spamed with all the windows server exploits). There's no reason not to support such a feature. If it accelerates the removal of windows servers all the better as it would give linux far more leverage over the small business market and do much to suppress Microsoft's tendency to fragment markets and create lockin, and that frankly is good for everyone.

It's petty and silly to suggest the community shouldn't bother with it.

Common needs for Samba and NFS

Cyberax — Wed, 15 May 2019 23:33:40 +0000

> Enterprise file storage
Not quite. It's "'enterprise' legacy storage for Windows clients".

Common needs for Samba and NFS

jra — Wed, 15 May 2019 23:16:01 +0000

Yes. It's opinion being asserted as fact. It's standing in the way of Linux progress in Enterprise file storage. The person asserting that clearly doesn't care, and that's their right of course. But what it does is promote fragmentation and closed source solutions, as they don't have to work with a standard Linux kernel to do what they want.

Common needs for Samba and NFS

Cyberax — Wed, 15 May 2019 23:05:24 +0000

POSIX ACLs are also not very well designed, but they're here so we have to live with them.

The problem with RichACLs is exactly that - they are way too rich and complicated. In particular, inheritance is a whole flaming garbage can.

Common needs for Samba and NFS

nix — Wed, 15 May 2019 22:58:11 +0000

The total lack of reason given for RichACLs being 'crap' is notable, too, though it is probably pointless to note that argument by assertion will not convince anyone. I mean it's not as if POSIX-draft ACLs are exactly a model of clarity and wonderfulness, either -- at least RichACLs model an ACL variant that is actually in wide use by real people, even if on Windows (duh: obviously, since Windows is the OS that has an ACL model closest to RichACLs). POSIX ACLs, despite being long-supported on Linux are... not used so much at all.

Common needs for Samba and NFS

Cyberax — Wed, 15 May 2019 21:20:36 +0000

> RichACL (or something similar) is probably still easier.
Yet this will require pretty much indefinite support of it in the mainline Linux, and deep inside VFS at that.

Common needs for Samba and NFS

smfrench — Wed, 15 May 2019 20:47:29 +0000

Common libraries for ACL integration between NFS (e.g. Ganesha server) and SMB3 servers (e.g. Samba) can be done, but given that the NFS kernel server is still commonly used, RichACL (or something similar) is probably still easier.

The NFS and SMB3 ACL models are reasonably similar so getting NFS and Samba server to agree on enforcement would help some of the cases, but note that this isn't just Windows clients that use (and expect to report to users and admins and tools) the 'RichACL' like format, Macs do as well, and presumably as government requirements get stricter (whether we like it or not), the presence of more complex ACLs with deny entries (one of the key differences between RichACL and the draft POSIX ACLs that Linux implements) is going to be hard to avoid, especially for systems accessed over the network.

Common needs for Samba and NFS

Cyberax — Wed, 15 May 2019 19:16:15 +0000

> Windows shops depend on them. I don't care if you personally like them or not, they're a required feature for enterprise-level storage for Windows clients.
Well, they should just remain on Windows then. Why should Linux get all the braindeadness of other OSes for the sake of a handful of mastodon companies?

Besides, there are things that really require kernel-level support like case insensitivity. ACLs do not, they can be done completely in user space. Even if you need NFS interoperability, you can still use user-level NFS servers and patch in support there.

Common needs for Samba and NFS

jra — Wed, 15 May 2019 19:03:22 +0000

Windows shops depend on them. I don't care if you personally like them or not, they're a required feature for enterprise-level storage for Windows clients.

It's the kind of attitude expressed above that gives Linux devs a bad name, unfortunately.

Common needs for Samba and NFS

Cyberax — Wed, 15 May 2019 18:42:23 +0000

I'm really glad that RichACLs died. It's just crap.

Common needs for Samba and NFS

jra — Wed, 15 May 2019 17:45:37 +0000

+1 on this. RichACLs are the single most important feature needed to allow users to migrate their Windows storage to Linux.