[Devel] Re: [PATCH 2/4] Expose may_setuid() in user.h

[Serge E. Hallyn]

Quoting Dan Smith (danms at us.ibm.com):
> Make this helper available to others.

No objection to exporting may_setuid, nor to creating may_setgid(),
but I don't think may_setgid() is right.  See below

> Signed-off-by: Dan Smith <danms at us.ibm.com>
> ---
>  include/linux/user.h |    9 +++++++++
>  kernel/user.c        |   16 +++++++++++++++-
>  2 files changed, 24 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/user.h b/include/linux/user.h
> index 68daf84..713bae7 100644
> --- a/include/linux/user.h
> +++ b/include/linux/user.h
> @@ -1 +1,10 @@
> +#ifndef _LINUX_USER_H
> +#define _LINUX_USER_H
> +
>  #include <asm/user.h>
> +#include <linux/sched.h>
> +
> +extern int may_setuid(struct user_namespace *ns, uid_t uid);
> +extern int may_setgid(struct group_info *groupinfo, gid_t gid);
> +
> +#endif
> diff --git a/kernel/user.c b/kernel/user.c
> index a535ed6..38b8b50 100644
> --- a/kernel/user.c
> +++ b/kernel/user.c
> @@ -604,7 +604,7 @@ int checkpoint_user(struct ckpt_ctx *ctx, void *ptr)
>  	return do_checkpoint_user(ctx, (struct user_struct *) ptr);
>  }
> 
> -static int may_setuid(struct user_namespace *ns, uid_t uid)
> +int may_setuid(struct user_namespace *ns, uid_t uid)
>  {
>  	/*
>  	 * this next check will one day become
> @@ -631,6 +631,20 @@ static int may_setuid(struct user_namespace *ns, uid_t uid)
>  	return 0;
>  }
> 
> +int may_setgid(struct group_info *groupinfo, gid_t gid)
> +{
> +	if (capable(CAP_SETGID))
> +		return 1;

We should pass in a user_ns so we can eventually check for
capable_to(ns, CAP_SETGID).  So the caller may not be
CAP_SETGID in the root user namespace, but may have created
the child user namespace and be privileged there.

> +	if (current_cred_xxx(group_info) != groupinfo)
> +		return 0;

I think it's possible for two different group_info's to have the same
member groups.

I think the thing to do is walk over all groups in group_info,
and do in_egroup_p(g) for each.

It's also possible that groups 1, 4, and 5 are in current_group_info and 6 is
current_egroup, while we're asking for a group_info with groups 1, 5 and 6, and
egid of 4.  That would be legal, right?  Walking over the groups and doing
in_egroup_p(g) should do that check.  Sure, it's n^2 on the # groups...  So
we could eventually optimize it to exploit the fact that both groupinfos
are sorted and keep last_used_g in both groupinfos...

> +	if (in_egroup_p(gid))
> +		return 1;
> +
> +	return 0;
> +}
> +
>  static struct user_struct *do_restore_user(struct ckpt_ctx *ctx)
>  {
>  	struct user_struct *u;
> -- 
> 1.6.0.4
> 
> _______________________________________________
> Containers mailing list
> Containers at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers