linux-kernel - Re: [RFC v3 42/45] nfs: Add richacl support

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, 29 May 2015 17:00:15 +0200
From:	Andreas Grünbacher <andreas.gruenbacher@...il.com>
To:	Trond Myklebust <trond.myklebust@...marydata.com>
Cc:	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>
Subject: Re: [RFC v3 42/45] nfs: Add richacl support

2015-05-29 15:15 GMT+02:00 Trond Myklebust <trond.myklebust@...marydata.com>:
> [reply reordered]
> So having revisited the reasons why I chose the system.nfs4_acl
> interface when we did NFSv4 ACLs, I'm not sure we should implement
> system.richacl for the NFS client at all.
>
> Your assertion that "when symbolic user@...ain and group@...ain names
> are used in the acl, user-space needs to perform ID mapping in the
> same way as the kernel"  is WRONG. User space needs do no such thing,
> and that was the whole point of the interface; to allow the user to
> specify ACLs in a format that is checked only on the _server_, and not
> on the client.

That's only half true. Right now, user-space applications trying to copy
permissions between an nfs mount and another file system will fail unless the
application has explicitly been made nfs aware and supports the
"system.nfs4_acl"
attribute (as well as some other acl mechanism if the permissions go beyond the
file mode).

The same problem exists when trying to make sense of acls.

It seems unreasonable to me to expect applications other than special file
system maintenance tools to cater to such file system differences; there are
just too many file systems out there for that to work. Instead, it
would be better
to use an interface that can be generalized across file systems.

> The problem is that you are 100% reliant on an accurate idmapper in
> order to convert the name@...ain to a _correct_ uid/gid. It isn't
> sufficient to convert to just any valid uid/gid, because if your ACL
> tool is trying to edit the ACL, you can end up converting all those
> DENY modes for user 'Johnny_Rotten@...ckhats.are.us' into DENY modes
> for user 'nobody'.
> ...and yes, libnfsidmap will happily convert all unknown
> user/groupnames into whatever uid/gid corresponds to 'nobody' without
> returning an error.

That's indeed a problem, and I can think of two ways of addressing it:

First, acl editors need to be careful about nobody entries; they need to be
aware that nobody could actually stand for somebody else. (We could map
unmappable users and groups to something else than nobody, but that
might just shift the problem without improve anything.)

Second, we could add support for passing through unmappable Who values
as is. But that raises the problem of how to pass thtough and represent
different kinds of identifiers: NFSv4 users user@...ain and group@...ain
strings; smb users SIDs; maybe more.

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