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]

Message-ID: <045601d09a27$cb8caaa0$62a5ffe0$@mindspring.com>
Date:	Fri, 29 May 2015 08:54:48 -0700
From:	"Frank Filz" <ffilzlnx@...dspring.com>
To:	"'Trond Myklebust'" <trond.myklebust@...marydata.com>,
	'Andreas Grünbacher' 
	<andreas.gruenbacher@...il.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>,
	"'Linux API Mailing List'" <linux-api@...r.kernel.org>
Subject: RE: [RFC v3 42/45] nfs: Add richacl support

> On Fri, May 29, 2015 at 11:00 AM, Andreas Grünbacher
> <andreas.gruenbacher@...il.com> wrote:
> > 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.
> 
> My point is that system.richacl is not such an interface. It can only ever work
> for local filesystems that understand and store local uids and gids. It has no
> support for the remote users/groups that are stored on your NFS/SMB
> server unless they happen to have a local mapping into uids and gids, and so
> the API is inappropriate to replace the existing NFSv4 acl API on the client.

Could we have both xattrs? Or a mount option that specifies which xattr to have?

That way folks who don't have local idmapping for every remote identity can use system.nfs4_acl while those who have local mapping for all remote identies and need to use a wide variety of tools can use system.richacl? system.richacl would obviously need to be documented that this issue can arise. But that will forever be an issue, unless we store the ACL with symbolic names, copying from a remote server to a local filesystem will always be lossy if the idmapping is incomplete.

Maybe that's too messy...

Frank


--
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/