Re: [PATCH -mm 0/9] unshare system call : updated patch series

[JANAK DESAI <janak@us.ibm.com>]

Andrew Morton wrote:

> JANAK DESAI <janak@us.ibm.com> wrote:
>  
>
> > The following patches represent the updated version of the proposed
> > new system call unshare. Patches that registered system call for
> > different architectures were not updated but are being resent in
> > the series along with the updated patches.
> >
> > Changes since the first submission of this patch series on 12/12/05:
> > 	- Patches 1, 6, 7, 8, and 9 are updated to incorporate
> > 	  feedback from Al Viro. Changes are described in the change
> > 	  log for each of the patches (12/13/05)
> >
> > unshare allows a process to disassociate part of the process context (vm
> > namespace, files and fs) that was being shared with a parent.  Unshare 
> > is needed to implement polyinstantiated directories (such as per-user 
> > and/or per-security context /tmp directory) using the kernel's per-process
> > namespace mechanism. For a more detailed description of the justification
> > and approach, please refer to lkml threads from 8/8/05, 10/13/05 & 12/08/05.
> >                                                                                
> > Unshare system call, along with shared tree patches, have been in use
> > in our department for over month and half. We have been using them to
> > maintain per-user and per-context /tmp directory. The latest port to
> > 2.6.15-rc5-mm2 has been tested on a uni-processor i386 machine.
> >    
>
> I wouldn't view this as an adequate changelog for a new feature, really. 
> Please prepare a new one which describes what the feature does, how it does
> it and, especially, why we would want to add it to the kernel.
>
> It adds 1.6k to my allnoconfig image which I guess can be lived with, but
> we need a *good* understanding of what we're getting for that cost, and
> apart from sending the reader onto an ill-defied lkml fishing expedition,
> you haven't provided that.
>
> Another downside which we need to weigh when evaluating this contribution
> is the security risk.  You've added code which very, very few people will
> use in real-life.  If it has holes or races they just won't be found by our
> normal testing processes.  Chances are the first time we'll hear about them
> is when some smarty has gone explicitly looking for exploits.
>
> Please demonstrate how each unsharing (fs, ns, sig, mm, fd) is correctly
> locked and refcounted against concurrent users.  I've only checked mm
> against access_process_vm() and it looks OK.
>
> Thanks.
> -
> 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/
>
>
>  
Thanks. Yes, I should have done a better job of describing this new 
feature. I remember
finding description of shared trees very useful and meant to emulate it 
for unshare, but
got caught up in code fixes and didn't update the documentation. I will 
do so soon and
send it out so you have a more coherent information from which to make a 
decision.

-Janak
-
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/