[lkml]   [2019]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] Please pull NFS client updates for 4.21
On Wed, Jan 02 2019, Linus Torvalds wrote:

> On Wed, Jan 2, 2019 at 2:42 PM Schumaker, Anna
> <> 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

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2019-01-03 05:54    [W:0.051 / U:6.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site