lkml.org 
[lkml]   [2007]   [Mar]   [24]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateSat, 24 Mar 2007 10:35:37 +0530
    FromSrivatsa Vaddagiri <>
    SubjectRe: [ckrm-tech] [PATCH 7/7] containers (V7): Container interface to nsproxy subsystem
    On Mon, Feb 12, 2007 at 12:15:28AM -0800, menage@google.com wrote:
    > +/*
    > + * Rules: you can only create a container if
    > + *     1. you are capable(CAP_SYS_ADMIN)
    > + *     2. the target container is a descendant of your own container
    > + */
    > +static int ns_create(struct container_subsys *ss, struct container *cont)
    > +{
    > +	struct nscont *ns;
    > +
    > +	if (!capable(CAP_SYS_ADMIN))
    > +		return -EPERM;
    
    Does this check break existing namespace semantics in a subtle way?
    It now requires that unshare() of namespaces by any task requires
    CAP_SYS_ADMIN capabilities.
    
    clone(.., CLONE_NEWUTS, ..)->copy_namespaces()->ns_container_clone()->
    	->container_clone()-> .. -> container_create() -> ns_create()
    
    Earlier, one could unshare his uts namespace w/o CAP_SYS_ADMIN
    capabilities. Now it is required. Is that fine? Don't know.
    
    I feel we can avoid this check totally and let the directory permissions
    take care of these checks.
    
    Serge, what do you think?
    
    -- 
    Regards,
    vatsa
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2007-03-24 06:01    [from the cache]
    ©2003-2008