Re: [GIT PULL] Please pull NFS client updates for 4.21

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

On Wed, Jan 02 2019, Linus Torvalds wrote:

> On Wed, Jan 2, 2019 at 2:42 PM Schumaker, Anna
> <Anna.Schumaker@netapp.com> wrote:
>>
>> We also were unable to track down a maintainer for Neil Brown's changes to
>> the generic cred code that are prerequisites to his RPC cred cleanup patches.
>> We've been asking around for several months without any response, so
>> hopefully it's okay to include those patches in this pull request.
>
> Looks ok to me, although I wonder what the semantics of cred_fscmp()
> are across namespaces?
>
> IOW, it seems potentially a bit suspicious to do cred_fscmp() if the
> two creds have different namnespaces? Hmm?
>
> Is there some reason that can't happen, or some reason it doesn't matter?
>
>                   Linus

Interesting question.
For the current use in NFS, it is consistent with existing practice to
ignore the name space.
NFS file accesses (when using the normal uid-based access checks) always
use the manifest uid of the process - the one returned by getuid() (or
more accurately, getfsuid()).
Maybe this is wrong?  Maybe we should always use from_kuid() or whatever
to get the uid/gid to send over the wire?

Anna/Trond: do you have thoughts on this?  If a process in a user
namespace accesses a file over NFS, should the UID presented to the
server be the one in that name-space, or the one you get by mapping to
the global name-space?
Or should we map to the namespace that was active when the filesystem
was mounted?

I don't think cred_fscmp() should do any of this mapping, but maybe it
should treat creds from different namespaces as different - as a
precaution.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]