Re: [PATCH -mm 5/7] add user namespace

[ebiederm@xmission.com (Eric W. Biederman)]

Kirill Korotaev <dev@sw.ru> writes:

>>>Another example of not so evident coupling here:
>>>user structure maintains number of processes/opened
> files/sigpending/locked_shm
>>>etc.
>>>if a single user can belong to different proccess/ipc/... namespaces
>>>all these becomes unusable.
>> Why do the count of the number of objects a user has become
>> unusable if they can count objects in multiple namespaces?
>> Namespaces are about how names are looked up and how names are
>> created.  Namespaces are not about the objects those names refer to.
>
> One example below, which I believe is a bug due to coupling.
> Will be glad to hear your opinion on this.
>
> Let user u to unshare its process namespace and run e.g. httpd inside newly
> created 2nd process namespace.
> Now imagine that user u hits his process rlimit.
> He can't kill his httpd's because they are in another process namespace. He can
> kill visible to his bash processes from
> 1st process namespace, but httpd can spawn childs more after that. So we end up
> with the situation
> when user u can't control his processes, nor run any other processes in his
> bash.

Yes, this can happen.   But as described this really is a usage problem.  I would
expect if your uid is in use in multiple places you will have accesses to all of
those places.  Part of this won't be clear until we sort out the process id
namespace though.

> I'm fine with such situations, since we need containers mostly, but what makes
> me
> really afraid is that it introduces hard to find/fix/maintain issues. I have no
> any other concerns.

Hard to find and maintain problems I agree should be avoided.  There are only two
ways I can see coping with the weird interactions that might occur.
1) Assert weird interactions will never happen, don't worry about it,
   and stomp on any place where they can occur.  (A fully isolated container approach).

2) Assume weird interactions happen and write the code so that it simply
   works if those interactions happen, because for each namespace you have
   made certain the code works regardless of which namespace the objects are
   in.

The second case is slightly harder.  But as far as I can tell it is more robust
and allows for much better incremental development.

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