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.
