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

[Andrew Morton]

JANAK DESAI <janak@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/