From: "firstname.lastname@example.org" <email@example.com> To: Trond Myklebust <firstname.lastname@example.org> Cc: "email@example.com" <firstname.lastname@example.org>, "Anna.Schumaker@netapp.com" <Anna.Schumaker@netapp.com> Subject: Re: [PATCH 6/9] NFSv4: Convert the NFS client idmapper to use the container user namespace Date: Thu, 25 Apr 2019 11:33:39 -0400 Message-ID: <20190425153339.GB8133@fieldses.org> (raw) In-Reply-To: <email@example.com> On Thu, Apr 25, 2019 at 03:00:22PM +0000, Trond Myklebust wrote: > The assumption is that if you have enough privileges to mount a > filesystem using the NFS client, then you would also have enough > privileges to run a userspace client, so there is little point in > restricting the NFS client. > > So the guiding principle is that a NFS client mount that is started in > a container should behave as if it were started by a process in a "real > VM". That means that the root uid/gid in the container maps to a root > uid/gid on the wire. > Ditto, if there is a need to run the idmapper in the container, then > the expectation is that processes running as 'user' with uid 'u', will > see their creds mapped correctly by the idmapper. Again, that's what > you would see if the process were running in a VM instead of a > container. > > Does that all make sense? Yes, thanks! I thought there was a problem that the idmapper depended on keyring usermodehelper calls that it was hard to pass namespace information to. Did that get fixed and I missed it or or forgot? > > So this means that any orchestrator software which may be setting up > NFS mounts as part of setting up the container has 2 options: > > 1. Either perform the mount outside the container namespaces, in which > case the container process uids/gids are mapped from their > user_namespace into the user_namespace of the orchestrator, and the > uids/gids on the wire will reflect those mapped uids/gids (so uid 0 > in the container will be mapped to uid xxx where xxx is decided by > the orchestrator). > 2. Perform the mount inside the container namespaces, in which case the > container process uids/gids go on the wire as-is. OK, great, that sounds perfect. --b.
next prev parent reply index Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-24 21:46 [PATCH 0/9] Client container fixes Trond Myklebust 2019-04-24 21:46 ` [PATCH 1/9] SUNRPC: Cache cred of process creating the rpc_client Trond Myklebust 2019-04-24 21:46 ` [PATCH 2/9] NFS: Store the credential of the mount process in the nfs_server Trond Myklebust 2019-04-24 21:46 ` [PATCH 3/9] SUNRPC: Use the client user namespace when encoding creds Trond Myklebust 2019-04-24 21:46 ` [PATCH 4/9] SUNRPC: Use namespace of listening daemon in the client AUTH_GSS upcall Trond Myklebust 2019-04-24 21:46 ` [PATCH 5/9] NFS: Convert NFSv3 to use the container user namespace Trond Myklebust 2019-04-24 21:46 ` [PATCH 6/9] NFSv4: Convert the NFS client idmapper " Trond Myklebust 2019-04-24 21:46 ` [PATCH 7/9] NFS: Convert NFSv2 " Trond Myklebust 2019-04-24 21:46 ` [PATCH 8/9] NFS: When mounting, don't share filesystems between different user namespaces Trond Myklebust 2019-04-24 21:46 ` [PATCH 9/9] lockd: Store the lockd client credential in struct nlm_host Trond Myklebust 2019-04-25 14:32 ` [PATCH 6/9] NFSv4: Convert the NFS client idmapper to use the container user namespace bfields 2019-04-25 15:00 ` Trond Myklebust 2019-04-25 15:33 ` bfields [this message] 2019-04-25 16:40 ` Trond Myklebust 2019-04-25 16:45 ` bfields 2019-04-25 16:48 ` Trond Myklebust 2019-04-25 20:16 ` bfields 2019-06-14 18:52 ` [PATCH 1/9] SUNRPC: Cache cred of process creating the rpc_client Ido Schimmel 2019-06-20 12:33 ` Ido Schimmel
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190425153339.GB8133@fieldses.org \ --firstname.lastname@example.org \ --cc=Anna.Schumaker@netapp.com \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-NFS Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-nfs/0 linux-nfs/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-nfs linux-nfs/ https://lore.kernel.org/linux-nfs \ email@example.com firstname.lastname@example.org public-inbox-index linux-nfs Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-nfs AGPL code for this site: git clone https://public-inbox.org/ public-inbox