linux-kernel - Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 May 2019 17:39:55 +0000
From:   "Goetz, Patrick G" <pgoetz@...h.utexas.edu>
To:     "J. Bruce Fields" <bfields@...ldses.org>
CC:     Andreas Gruenbacher <agruenba@...hat.com>,
        NeilBrown <neilb@...e.com>, Amir Goldstein <amir73il@...il.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Andreas Grünbacher 
        <andreas.gruenbacher@...il.com>,
        Patrick Plagwitz <Patrick_Plagwitz@....de>,
        "linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>,
        Linux NFS list <linux-nfs@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

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.