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: <CAHQdGtTiMEJHExwAa0W1dK6WZFth3Gk9nFjsKDADyJbKaXMcfw@mail.gmail.com>
Date:	Fri, 29 May 2015 11:54:48 -0400
From:	Trond Myklebust <trond.myklebust@...marydata.com>
To:	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:45 AM, Andreas Grünbacher
<andreas.gruenbacher@...il.com> wrote:
> 2015-05-29 17:24 GMT+02:00 Trond Myklebust <trond.myklebust@...marydata.com>:
>>> 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.
>
> That can be changed if we find a reasonable solution.
>
>>>> 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.)
>>
>> What is the editor supposed to do about an entry it cannot even
>> interpret, let alone store back to the server?
>
> In the end, it will have to be a user decision what to do about such entries,
> the editor can warn the user and make it harder to make mistakes though.
>
>>> 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.
>>
>> Now you have a mixture of some stuff that is being translated into
>> local uid/gid format and therefore needs translating back when you're
>> going to update the ACL, and some stuff that is not. What is the value
>> of doing the mapping here?
>
> If you don't translate, you cannot copy the permissions to another file
> system. In the ideal case, everything can be translated; where that fails,
> the user probably wants to know.

Why are we more worried about a hypothetical copy of the file to
another filesystem than we are about representing the ACL correctly
for the filesystem that the file is actually on? Your ACL on the
remote SMB server windows.publicserver.com may not be fully
represented when you copy the file to your local filesystem; get over
it... However if you are authorised to edit the ACL on
windows.publicserver.com, and you can't set it to something that can
be enforced correctly by windows.publicserver.com, then you have a
real problem.

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