Re: [PATCH 2/4] fs: allow dev accesses in userns in controlled situations

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Janne Karhunen <janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> On Tue, Mar 19, 2013 at 5:37 PM, Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> wrote:
>
>>> > Well the devcg was meant to be a temporary stopgap solution until we
>>> > have device namespaces, and this seems to entrench them further, but
>>> > it does make sense.
>>>
>>> Just out of interest, what would such device namespace actually
>>> do other than switch the device access on/off according to callers
>>> namespace?
>>
>> It could also support mapping of <type>:maj:min inside namespace to
>> a different device on host.  In most cases we probably don't actually
>> want that, but it's an interesting enough thing to be worth thinking
>> through.
>
> It sounds to me that what you really want to do is likely use case and
> device specific. Hence the idea about namespace specific ioctl device
> action(s) might not be so bad. It would certainly be less intrusive than
> tampering with device registrations or rerouting nod file_operations for
> instance.
>
> Classic on/off toggle case is easy though, but are there enough
> reasons for merging such 'noop' namespace?

The two most compelling cases are:
- Container migration.
- Safe creation of virtual devices.

Now I think we can solve container migration by effectively hotuplugging
and hotplugging all of our devices.

The safe creation of virtual devices that I am thinking of are
essentially ptys (already covered with devpts) and loopback devices.
There are probably a couple more that I don't know off the top of my
head.

So far I haven't found any case that is sufficiently compelling, and
can't be replaced by acting like devtmpfs and controlling all device
creation.  Although I have heard of cases where applications still call
mknod even with devtmpfs and udev doing most of the work.

I am of the general thought that we should explore what we can do with
what we have now, at least until we find a compelling case for doing
more in the kernel.

Eric