Re: [PATCH review 48/85] sunrpc: Update gss uid to security contextmapping.

[J. Bruce Fields]

On Wed, Feb 13, 2013 at 01:17:37PM -0800, Eric W. Biederman wrote:
> "J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes:
> 
> > On Wed, Feb 13, 2013 at 09:51:37AM -0800, Eric W. Biederman wrote:
> >> From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
> >> 
> >> - Use from_kuid when generating the on the wire uid values.
> >> - Use make_kuid when reading on the wire values.
> >> 
> >> In gss_encode_v0_msg, since the uid in gss_upcall_msg is now a kuid_t
> >> generate the necessary uid_t value on the stack copy it into
> >> gss_msg->databuf where it can safely live until the message is no
> >> longer needed.
> >
> > Apologies, I haven't been following the user namespace work.
> >
> > If I understand correctly, you're expecting the id's seen in nfs
> > protocol messages to be the same as the id's seen in the initial user
> > namespace.
> >
> > Why is that right, and not, say, the user namespace in which the mount
> > was originally performed?  (Just asking, I honestly haven't thought
> > about it before.)
> 
> Actually my expectation is the user namespace was originally performed
> in.  Currently nfs doesn't support being  mounted in anything other
> than the initial user namespace.
> 
> > Also:
> >
> >> diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
> >> index afbbcfb..a360067 100644
> >> --- a/net/sunrpc/auth_gss/auth_gss.c
> >> +++ b/net/sunrpc/auth_gss/auth_gss.c
> >> @@ -395,8 +395,11 @@ gss_upcall_callback(struct rpc_task *task)
> >>  
> >>  static void gss_encode_v0_msg(struct gss_upcall_msg *gss_msg)
> >>  {
> >> -	gss_msg->msg.data = &gss_msg->uid;
> >> -	gss_msg->msg.len = sizeof(gss_msg->uid);
> >> +	uid_t uid = from_kuid(&init_user_ns, gss_msg->uid);
> >> +	memcpy(gss_msg->databuf, &uid, sizeof(uid));
> >> +	gss_msg->msg.data = gss_msg->databuf;
> >> +	gss_msg->msg.len = sizeof(uid);
> >> +	BUG_ON(sizeof(uid) > UPCALL_BUF_LEN);
> >
> > This message is going to gssd, not to the server.  Should it be encoded
> > for whatever namespace gssd lives in?
> 
> Good basic question.  The immediate answer is that right now I only
> support these things living in user namespace the filesystem was
> mounted in, aka the initial user namespace.
> 
> There are a handful of things ioctls, and a quota call or two that I
> will translate into the callers user namespace.  For network filesystems
> and their specialized helpers it would be lossy and unnecessarily
> complex to support arbitrary pieces living in different user namespaces.
> Historically unix has had syncrhonized password databases to ensure even
> multiple machines effectively had the same user namespace.
> 
> The really important step for me is to have the kernel using kuid_t and
> kgid_t throughout and only converting when talking outside of the kernel
> (disk, filesystem on disk data structures, network).
> 
> With that step I can enable user namespaces and the various filesystems.
> And even if the filesystem itself is restricted to just one user
> namespace, the users who read and write files on that filesystem won't
> be.
> 
> A next step for the filesystems where this is interesting is to support
> a user who is not the global root mounting the filesystem and having the
> filesystem speak in ids in the user namespace that the filesystem was
> mounted in.  That takes a little bit of connecting the dots of which
> user namespace goes where, and it takes a little bit of confidence that
> the kernel won't fall over if an evil server sends us deliberately bad
> protocol messages.  I suspect at some point someone will want to figure
> all of that out for nfs, certainly there has been work to figure that
> out for network namespaces.
> 
> For now though I am happy to have kuid_t and kgid_t pushed down
> everywhere they should be.

OK, makes sense, thanks for the explanation.--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/