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  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]
Date:	Fri, 16 Oct 2015 20:12:38 +0200
From:	Andreas Gruenbacher <>
To:	Andreas Grünbacher <>
Cc:	"J. Bruce Fields" <>,
	Alexander Viro <>,
	"Theodore Ts'o" <>,
	Andreas Dilger <>,
	Jeff Layton <>,
	Trond Myklebust <>,
	Anna Schumaker <>,
	linux-ext4 <>,
	Linux Kernel Mailing List <>,
	Linux FS-devel Mailing List <>,
	Linux NFS Mailing List <>,
	Linux API Mailing List <>
Subject: Re: [PATCH v8 00/41] Richacls

On Tue, Sep 29, 2015 at 4:54 PM, Andreas Grünbacher
<> wrote:
> 2015-09-28 19:46 GMT+02:00 J. Bruce Fields <>:
>> 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 <>:
>>> > 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.)

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists