On 5/3/19 10:27 AM, J. Bruce Fields wrote:
> Christoph also had some objections to the implementation which I think
> were addressed, but I could be wrong.
I'm certainly no expert, but yes, the objections to the RichACL patches
were addressed and not really counter challenged. It seems like a case
of Windows ACLs are yucky and complicated and not needed in all linux
environments (which, by the way, I've learned isn't entirely true).
-----------------------------------------
Christoph Hellwig:
> For one I still see no reason to merge this broken ACL model at all.
> It provides our actualy Linux users no benefit at all, while breaking
> a lot of assumptions, especially by adding allow and deny ACE at the
> same sime.
From: Andreas Gruenbacher:
This permission model is useful in mixed environments that involve
UNIX and Windows machines. Think of NAS boxes with Linux and Windows
clients, for example. It also fits the NFSv4 ACL model very well. If
you're not a user dealing with such environments, then the model
likely won't provide any benefits to *you*, and you're better off with
a less complicated permission model. That doesn't say anything about
other users, though.
-----------------------------------------
and here:
-----------------------------------------
Christoph Hellwig:
> It also doesn't help with the issue that the main thing it's trying
> to be compatible with (Windows) actually uses a fundamentally
> different identifier to apply the ACLs to - as long as you're
> still limited to users and groups and not guids we'll still
> have that mapping problem anyway.
From: Andreas Gruenbacher:
Samba has been dealing with mapping between SIDs and UIDs/GIDs for a
long time, and it's working acceptably well.
We could store SIDs in ACEs, but that wouldn't make the actual
problems go away: Files on Linux have an owner and an owning group
which are identitifed by UID/GID, whereas a file is owned by a SID
which can be either a user or a group in a SID world. Also, processes
on Linux have an owner and a list of groups which are identified by
UID/GID, so any SIDs stored in filesystems would never match a
process, anyway.
(NFSv4 refers to users and groups as opposed to SIDs, and so it
doesn't have this problem.)
-----------------------------------------
Further, the counterarguments seem weak, at best:
> People have long learned that we only have 'alloc' permissions. Any
> model that mixes allow and deny ACE is a mistake.
As someone pointed out elsewhere in the thread, linux people are
hopefully used to learning new tricks.
Who these days has the luxury of not working in a mixed environment? I
agree that Windows ACLs are kind of gross and overly complicated (and as
a result, many people don't use them at all and end up with low security
permission environments), but the professional Windows admins I know do
use them, and we've had a number of use cases already where permissions
problems are simply solved using Windows ACLs, impossible to get just
right with mode bits and POSIX ACLs. Not having RichACLs just makes it
really easy for the Windows storage people to win every argument.
The SID <--> UID thing is manageable; we're doing it now. Dealing with
groups is a bit harder. What I've been doing is continuing to use
/etc/group, but populating the entries with the usernames associated
with SIDs (which in our case are mapped directly to UIDs). For files
owned by a group SID, the simple solution is just to treat this SID as a
dummy UID. I haven't had to use this yet, but it seems like it should
work. sssd has made much of this more manageable. The missing killer
feature is a somewhat unified authorization model.
The fact that Windows assigns SIDs to machines is actually a major
technological advantage over the UNIX/linux model (this sure would
simplify NFS, for example), but then they had the advantages of
hindsight. And that's just an aside anyway.