linux-ext4 - Re: [PATCH v8 00/41] Richacls

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] [day] [month] [year] [list]

Message-ID: <CAHc6FU4rE0Tf9Lfr3wD-+y3GCaiExtZn1onz0E56zDumjXw+3Q@mail.gmail.com>
Date:	Fri, 16 Oct 2015 20:12:38 +0200
From:	Andreas Gruenbacher <agruenba@...hat.com>
To:	Andreas Grünbacher <andreas.gruenbacher@...il.com>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	"Theodore Ts'o" <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Jeff Layton <jlayton@...chiereds.net>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	Anna Schumaker <anna.schumaker@...app.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Linux API Mailing List <linux-api@...r.kernel.org>
Subject: Re: [PATCH v8 00/41] Richacls

On Tue, Sep 29, 2015 at 4:54 PM, Andreas Grünbacher
<andreas.gruenbacher@...il.com> wrote:
> 2015-09-28 19:46 GMT+02:00 J. Bruce Fields <bfields@...ldses.org>:
>> On Mon, Sep 28, 2015 at 07:10:06PM +0200, Andreas Grünbacher wrote:
>>> 2015-09-28 18:35 GMT+02:00 J. Bruce Fields <bfields@...ldses.org>:
>>> > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote:
>>> >> Open issues in nfs:
>>> >>
>>> >> * When a user or group name cannot be mapped, nfs's idmapper always maps it
>>> >>   to nobody. That's good enough for mapping the file owner and owning
>>> >>   group, but not for identifiers in acls. For now, to get the nfs richacl
>>> >>   support somewhat working, I'm explicitly checking if mapping has resulted
>>> >>   in uid/gid 99 in the kernel.
>>> >>
>>> >> * When the nfs server replies with NFS4ERR_BADNAME for any user or group
>>> >>   name lookup, the client will stop sending numeric uids and gids to the
>>> >>   server even when the lookup wasn't numeric.  From then on, the client
>>> >>   will translate uids and gids that have no mapping to the string "nobody",
>>> >>   and the server will reject them.  This problem is not specific to acls.
>>> >
>>> > Do you have fixes in mind for these two issues?
>>>
>>> I'm not sure how to best fix the idmapper problem, with backwards
>>> compatibility and all.
>>
>> I haven't looked at the current nfsidmap interface....  So it's
>> completely lacking any way to communicate failure?
>
> Yes, when a user doesn't exist, idmapper maps that to the nobody
> uid/gid. That's the failure mode of stat. In the acl case, we do want
> to map user and group names to their respective ids where possible (so
> that the acl makes sense in the local system context), but we do want
> to preserve the original user and group names when there is no such
> mapping instead of mapping to the nobody uid/gid.

So that's fixed now in nfs-utils and the latest richacl snapshot.

>>> The second problem shouldn't be too hard to fix.
>>
>> Is it enough to turn off the failover in the case there's no possibility
>> it could have been caused by a numeric id?
>
> Yes, I believe that would be enough.
>
>> If any user can set ACLs with arbitrary strings as names, then we'd be
>> giving any user unprivileged user the ability to turn off numeric
>> idmapping, so I think we need to fix that.
>
> The bug can be triggered by unprivileged users with nfs4_setfacl.

It turns out that when setting an ACL, the ACL can contain UID/GID
numbers as well as user@...ain strings which the server cannot map.
The status code is NFS4ERR_BADNAME both when the server doesn't
support UID/GID numbers and when it cannot map a name, so in that
case, we cannot tell the difference.

Luckily, when a UID/GID cannot be mapped to a name, nfs falls back to
sending the server a UID/GID number instead even when
NFS_CAP_UIDGID_NOMAP has been cleared. So unprivileged users can turn
on the idmapper, but at least that doesn't break unmapped UIDs/GIDs.
(I got that wrong in my initial analysis.)

Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html