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