OpenVZ Forum - RDF feed
type: channel
items: [RFC][PATCH] Devices visibility container
items: Re: [RFC][PATCH] Devices visibility container

[RFC][PATCH] Devices visibility container
type: item
description: Hi. At KS we have pointed out the need in some container, that allows to limit the visibility of some devices to task within it. I.e. allow for /dev/null, /dev/zero etc, but disable (by default) some IDE devices or SCSI discs and so on. Here's the beta of the container. Currently this only allows to hide the _character_ devices only from the living tasks. To play with it you just create the container like this # mount -t container none /cont/devs -o devices # mkdir /cont/devs/0 it will have two specific files # ls /cont/devs devices.block devices.char notify_on_release releasable release_agent tasks then move a task into it # /bin/echo -n $$ > /cont/devs/0/tasks after this you won't be able to read from even /dev/zero # hexdump /dev/zero hexdump: /dev/zero: No such device or address hexdump: /dev/zero: Bad file descriptor meanwhile from another ssh session you will. You may allow access to /dev/zero like this # /bin/echo -n '+1:5' > /cont/devs/0/devices.char More generally, the '+<major>:<minor>' string grants access to some device, and '-<major>:<minor>' disables one. The TODO list now looks like this: * add the block devices support :) don't know how to make it yet; * make /proc/devices show relevant info depending on who is reading it. currently even if major 1 is disabled for task, it will be listed in this file; * make it possible to enable/disable not just individual major:minor pair, but something more flexible, e.g. major:* for all minors for given major or major:m1-m2 for minor range, etc; * add the ability to restrict the read/write permissions for a container. currently one may just control the visible-invisible state for a device in a container, but maybe just readable or just writable would be better. This patch is minimally tested, because I just want to know your opinion on whether it worths developing the container in such a way or not. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- diff --git a/drivers/base/map.c b/drivers/base/map.c index e8…
creator: Pavel Emelianov
date: 2007-09-24T08:28:19-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Pavel Emelyanov wrote: > Hi. > > At KS we have pointed out the need in some container, that allows > to limit the visibility of some devices to task within it. I.e. > allow for /dev/null, /dev/zero etc, but disable (by default) some > IDE devices or SCSI discs and so on. > > Here's the beta of the container. Currently this only allows to > hide the _character_ devices only from the living tasks. To play > with it you just create the container like this > > # mount -t container none /cont/devs -o devices > # mkdir /cont/devs/0 > > it will have two specific files > > # ls /cont/devs > devices.block devices.char notify_on_release releasable release_agent tasks > > then move a task into it > > # /bin/echo -n $$ > /cont/devs/0/tasks > > after this you won't be able to read from even /dev/zero > > # hexdump /dev/zero > hexdump: /dev/zero: No such device or address > hexdump: /dev/zero: Bad file descriptor > > meanwhile from another ssh session you will. You may allow access > to /dev/zero like this > > # /bin/echo -n '+1:5' > /cont/devs/0/devices.char > > More generally, the '+<major>:<minor>' string grants access to > some device, and '-<major>:<minor>' disables one. > > The TODO list now looks like this: > * add the block devices support :) don't know how to make it yet; I think the mapping is done trough a pseudo-fs for the block devices. It probably means that we will have to mount it multiple times to handle the isolation. > * make /proc/devices show relevant info depending on who is > reading it. currently even if major 1 is disabled for task, > it will be listed in this file; > * make it possible to enable/disable not just individual major:minor > pair, but something more flexible, e.g. major:* for all minors > for given major or major:m1-m2 for minor range, etc; yep. > * add the ability to restrict the read/write permissions for a > container. currently one may just control the visible-invisible > state for a device in a container, but maybe just readable or > jus…
creator: Cedric Le Goater
date: 2007-09-24T09:55:14-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Cedric Le Goater wrote: > Pavel Emelyanov wrote: >> Hi. >> >> At KS we have pointed out the need in some container, that allows >> to limit the visibility of some devices to task within it. I.e. >> allow for /dev/null, /dev/zero etc, but disable (by default) some >> IDE devices or SCSI discs and so on. >> >> Here's the beta of the container. Currently this only allows to >> hide the _character_ devices only from the living tasks. To play >> with it you just create the container like this >> >> # mount -t container none /cont/devs -o devices >> # mkdir /cont/devs/0 >> >> it will have two specific files >> >> # ls /cont/devs >> devices.block devices.char notify_on_release releasable release_agent tasks >> >> then move a task into it >> >> # /bin/echo -n $$ > /cont/devs/0/tasks >> >> after this you won't be able to read from even /dev/zero >> >> # hexdump /dev/zero >> hexdump: /dev/zero: No such device or address >> hexdump: /dev/zero: Bad file descriptor >> >> meanwhile from another ssh session you will. You may allow access >> to /dev/zero like this >> >> # /bin/echo -n '+1:5' > /cont/devs/0/devices.char >> >> More generally, the '+<major>:<minor>' string grants access to >> some device, and '-<major>:<minor>' disables one. >> >> The TODO list now looks like this: >> * add the block devices support :) don't know how to make it yet; > > I think the mapping is done trough a pseudo-fs for the block devices. > It probably means that we will have to mount it multiple times to > handle the isolation. Maybe. I looked over the block layer and found that character one was simpler to start with. >> * make /proc/devices show relevant info depending on who is >> reading it. currently even if major 1 is disabled for task, >> it will be listed in this file; >> * make it possible to enable/disable not just individual major:minor >> pair, but something more flexible, e.g. major:* for all minors >> for given major or major:m1-m2 for minor range, etc; > > yep. :) >> * add the ability …
creator: Pavel Emelianov
date: 2007-09-24T11:47:26-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > Hi. > > At KS we have pointed out the need in some container, that allows > to limit the visibility of some devices to task within it. I.e. > allow for /dev/null, /dev/zero etc, but disable (by default) some > IDE devices or SCSI discs and so on. > > Here's the beta of the container. Currently this only allows to > hide the _character_ devices only from the living tasks. To play > with it you just create the container like this > > # mount -t container none /cont/devs -o devices > # mkdir /cont/devs/0 > > it will have two specific files > > # ls /cont/devs > devices.block devices.char notify_on_release releasable release_agent tasks > > then move a task into it > > # /bin/echo -n $$ > /cont/devs/0/tasks > > after this you won't be able to read from even /dev/zero > > # hexdump /dev/zero > hexdump: /dev/zero: No such device or address > hexdump: /dev/zero: Bad file descriptor > > meanwhile from another ssh session you will. You may allow access > to /dev/zero like this > > # /bin/echo -n '+1:5' > /cont/devs/0/devices.char > > More generally, the '+<major>:<minor>' string grants access to > some device, and '-<major>:<minor>' disables one. > > The TODO list now looks like this: > * add the block devices support :) don't know how to make it yet; > * make /proc/devices show relevant info depending on who is > reading it. currently even if major 1 is disabled for task, > it will be listed in this file; > * make it possible to enable/disable not just individual major:minor > pair, but something more flexible, e.g. major:* for all minors > for given major or major:m1-m2 for minor range, etc; > * add the ability to restrict the read/write permissions for a > container. currently one may just control the visible-invisible > state for a device in a container, but maybe just readable or > just writable would be better. > > This patch is minimally tested, because I just want to know your > opinion on whether it worths developing the…
creator: serue
date: 2007-09-24T14:39:15-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> Hi. >> >> At KS we have pointed out the need in some container, that allows >> to limit the visibility of some devices to task within it. I.e. >> allow for /dev/null, /dev/zero etc, but disable (by default) some >> IDE devices or SCSI discs and so on. >> >> Here's the beta of the container. Currently this only allows to >> hide the _character_ devices only from the living tasks. To play >> with it you just create the container like this >> >> # mount -t container none /cont/devs -o devices >> # mkdir /cont/devs/0 >> >> it will have two specific files >> >> # ls /cont/devs >> devices.block devices.char notify_on_release releasable release_agent tasks >> >> then move a task into it >> >> # /bin/echo -n $$ > /cont/devs/0/tasks >> >> after this you won't be able to read from even /dev/zero >> >> # hexdump /dev/zero >> hexdump: /dev/zero: No such device or address >> hexdump: /dev/zero: Bad file descriptor >> >> meanwhile from another ssh session you will. You may allow access >> to /dev/zero like this >> >> # /bin/echo -n '+1:5' > /cont/devs/0/devices.char >> >> More generally, the '+<major>:<minor>' string grants access to >> some device, and '-<major>:<minor>' disables one. >> >> The TODO list now looks like this: >> * add the block devices support :) don't know how to make it yet; >> * make /proc/devices show relevant info depending on who is >> reading it. currently even if major 1 is disabled for task, >> it will be listed in this file; >> * make it possible to enable/disable not just individual major:minor >> pair, but something more flexible, e.g. major:* for all minors >> for given major or major:m1-m2 for minor range, etc; >> * add the ability to restrict the read/write permissions for a >> container. currently one may just control the visible-invisible >> state for a device in a container, but maybe just readable or >> just writable would be better. >> >> This patch is minimally tested, be…
creator: Pavel Emelianov
date: 2007-09-24T14:58:10-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > Serge E. Hallyn wrote: > > Quoting Pavel Emelyanov (xemul@openvz.org): > >> Hi. > >> > >> At KS we have pointed out the need in some container, that allows > >> to limit the visibility of some devices to task within it. I.e. > >> allow for /dev/null, /dev/zero etc, but disable (by default) some > >> IDE devices or SCSI discs and so on. > >> > >> Here's the beta of the container. Currently this only allows to > >> hide the _character_ devices only from the living tasks. To play > >> with it you just create the container like this > >> > >> # mount -t container none /cont/devs -o devices > >> # mkdir /cont/devs/0 > >> > >> it will have two specific files > >> > >> # ls /cont/devs > >> devices.block devices.char notify_on_release releasable release_agent tasks > >> > >> then move a task into it > >> > >> # /bin/echo -n $$ > /cont/devs/0/tasks > >> > >> after this you won't be able to read from even /dev/zero > >> > >> # hexdump /dev/zero > >> hexdump: /dev/zero: No such device or address > >> hexdump: /dev/zero: Bad file descriptor > >> > >> meanwhile from another ssh session you will. You may allow access > >> to /dev/zero like this > >> > >> # /bin/echo -n '+1:5' > /cont/devs/0/devices.char > >> > >> More generally, the '+<major>:<minor>' string grants access to > >> some device, and '-<major>:<minor>' disables one. > >> > >> The TODO list now looks like this: > >> * add the block devices support :) don't know how to make it yet; > >> * make /proc/devices show relevant info depending on who is > >> reading it. currently even if major 1 is disabled for task, > >> it will be listed in this file; > >> * make it possible to enable/disable not just individual major:minor > >> pair, but something more flexible, e.g. major:* for all minors > >> for given major or major:m1-m2 for minor range, etc; > >> * add the ability to restrict the read/write permissions for a > >> container. currently one may just control the visible-invisib…
creator: serue
date: 2007-09-24T15:20:01-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): > >>Serge E. Hallyn wrote: >> >>>Quoting Pavel Emelyanov (xemul@openvz.org): >>> >>>>Hi. >>>> >>>>At KS we have pointed out the need in some container, that allows >>>>to limit the visibility of some devices to task within it. I.e. >>>>allow for /dev/null, /dev/zero etc, but disable (by default) some >>>>IDE devices or SCSI discs and so on. >>>> >>>>Here's the beta of the container. Currently this only allows to >>>>hide the _character_ devices only from the living tasks. To play >>>>with it you just create the container like this >>>> >>>> # mount -t container none /cont/devs -o devices >>>> # mkdir /cont/devs/0 >>>> >>>>it will have two specific files >>>> >>>> # ls /cont/devs >>>>devices.block devices.char notify_on_release releasable release_agent tasks >>>> >>>>then move a task into it >>>> >>>> # /bin/echo -n $$ > /cont/devs/0/tasks >>>> >>>>after this you won't be able to read from even /dev/zero >>>> >>>> # hexdump /dev/zero >>>>hexdump: /dev/zero: No such device or address >>>>hexdump: /dev/zero: Bad file descriptor >>>> >>>>meanwhile from another ssh session you will. You may allow access >>>>to /dev/zero like this >>>> >>>> # /bin/echo -n '+1:5' > /cont/devs/0/devices.char >>>> >>>>More generally, the '+<major>:<minor>' string grants access to >>>>some device, and '-<major>:<minor>' disables one. >>>> >>>>The TODO list now looks like this: >>>>* add the block devices support :) don't know how to make it yet; >>>>* make /proc/devices show relevant info depending on who is >>>> reading it. currently even if major 1 is disabled for task, >>>> it will be listed in this file; >>>>* make it possible to enable/disable not just individual major:minor >>>> pair, but something more flexible, e.g. major:* for all minors >>>> for given major or major:m1-m2 for minor range, etc; >>>>* add the ability to restrict the read/write permissions for a >>>> container. currently one may just control the visib…
creator: dev
date: 2007-09-24T15:31:19-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> Serge E. Hallyn wrote: >>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>> Hi. >>>> >>>> At KS we have pointed out the need in some container, that allows >>>> to limit the visibility of some devices to task within it. I.e. >>>> allow for /dev/null, /dev/zero etc, but disable (by default) some >>>> IDE devices or SCSI discs and so on. >>>> >>>> Here's the beta of the container. Currently this only allows to >>>> hide the _character_ devices only from the living tasks. To play >>>> with it you just create the container like this >>>> >>>> # mount -t container none /cont/devs -o devices >>>> # mkdir /cont/devs/0 >>>> >>>> it will have two specific files >>>> >>>> # ls /cont/devs >>>> devices.block devices.char notify_on_release releasable release_agent tasks >>>> >>>> then move a task into it >>>> >>>> # /bin/echo -n $$ > /cont/devs/0/tasks >>>> >>>> after this you won't be able to read from even /dev/zero >>>> >>>> # hexdump /dev/zero >>>> hexdump: /dev/zero: No such device or address >>>> hexdump: /dev/zero: Bad file descriptor >>>> >>>> meanwhile from another ssh session you will. You may allow access >>>> to /dev/zero like this >>>> >>>> # /bin/echo -n '+1:5' > /cont/devs/0/devices.char >>>> >>>> More generally, the '+<major>:<minor>' string grants access to >>>> some device, and '-<major>:<minor>' disables one. >>>> >>>> The TODO list now looks like this: >>>> * add the block devices support :) don't know how to make it yet; >>>> * make /proc/devices show relevant info depending on who is >>>> reading it. currently even if major 1 is disabled for task, >>>> it will be listed in this file; >>>> * make it possible to enable/disable not just individual major:minor >>>> pair, but something more flexible, e.g. major:* for all minors >>>> for given major or major:m1-m2 for minor range, etc; >>>> * add the ability to restrict the read/write permissions for a >>>> container. currently one may just c…
creator: Pavel Emelianov
date: 2007-09-24T15:31:57-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > Serge E. Hallyn wrote: > > Quoting Pavel Emelyanov (xemul@openvz.org): > >> Serge E. Hallyn wrote: > >>> Quoting Pavel Emelyanov (xemul@openvz.org): > >>>> Hi. > >>>> > >>>> At KS we have pointed out the need in some container, that allows > >>>> to limit the visibility of some devices to task within it. I.e. > >>>> allow for /dev/null, /dev/zero etc, but disable (by default) some > >>>> IDE devices or SCSI discs and so on. > >>>> > >>>> Here's the beta of the container. Currently this only allows to > >>>> hide the _character_ devices only from the living tasks. To play > >>>> with it you just create the container like this > >>>> > >>>> # mount -t container none /cont/devs -o devices > >>>> # mkdir /cont/devs/0 > >>>> > >>>> it will have two specific files > >>>> > >>>> # ls /cont/devs > >>>> devices.block devices.char notify_on_release releasable release_agent tasks > >>>> > >>>> then move a task into it > >>>> > >>>> # /bin/echo -n $$ > /cont/devs/0/tasks > >>>> > >>>> after this you won't be able to read from even /dev/zero > >>>> > >>>> # hexdump /dev/zero > >>>> hexdump: /dev/zero: No such device or address > >>>> hexdump: /dev/zero: Bad file descriptor > >>>> > >>>> meanwhile from another ssh session you will. You may allow access > >>>> to /dev/zero like this > >>>> > >>>> # /bin/echo -n '+1:5' > /cont/devs/0/devices.char > >>>> > >>>> More generally, the '+<major>:<minor>' string grants access to > >>>> some device, and '-<major>:<minor>' disables one. > >>>> > >>>> The TODO list now looks like this: > >>>> * add the block devices support :) don't know how to make it yet; > >>>> * make /proc/devices show relevant info depending on who is > >>>> reading it. currently even if major 1 is disabled for task, > >>>> it will be listed in this file; > >>>> * make it possible to enable/disable not just individual major:minor > >>>> pair, but something more flexible, e.g. major:* for all minors > >>>> for given major or …
creator: serue
date: 2007-09-24T15:51:39-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: [ ... ] > Maybe it's best if i just code up an example. I'll be gone part of the > week, and should send out new versions of some other patches first, but > getting two approaches to this to compare and contrast can't hurt. I guess we will need a control group subsystem in both approach, right ? C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-09-24T15:57:12-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Quoting Cedric Le Goater (clg@fr.ibm.com): > [ ... ] > > > Maybe it's best if i just code up an example. I'll be gone part of the > > week, and should send out new versions of some other patches first, but > > getting two approaches to this to compare and contrast can't hurt. > > I guess we will need a control group subsystem in both approach, right ? Yes. Pavel's has one, and I would use one both for task tracking and to use the cgroup vfs interface to construct the device whitelists. thanks, -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-09-24T16:18:23-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Pavel Emelyanov <xemul@openvz.org> writes: > Hi. > > At KS we have pointed out the need in some container, that allows > to limit the visibility of some devices to task within it. I.e. > allow for /dev/null, /dev/zero etc, but disable (by default) some > IDE devices or SCSI discs and so on. NAK We do not want a control group subsystem for this. For the short term we can just drop CAP_SYS_MKNOD. For the long term we need a device namespace for application migration, so they can continue to use devices with the same major+minor number pair after the migration event. Things like ensuring a call to stat on a given file before and after the migration return the exact same information sounds compelling. So I don't think this is even strictly limited to virtual devices anymore. How many applications are there out there that memorize the stat data on a file and so they can detect if it has changed? If we need something between those two it may make sense to enhance the LSM or perhaps introduce an alternate set security hooks. Still if we are going to need a full device namespace that may be a little much. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-09-24T16:47:50-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Quoting Kirill Korotaev (dev@sw.ru): > Serge E. Hallyn wrote: > > Quoting Pavel Emelyanov (xemul@openvz.org): > > > >>Serge E. Hallyn wrote: > >> > >>>Quoting Pavel Emelyanov (xemul@openvz.org): > >>> > >>>>Hi. > >>>> > >>>>At KS we have pointed out the need in some container, that allows > >>>>to limit the visibility of some devices to task within it. I.e. > >>>>allow for /dev/null, /dev/zero etc, but disable (by default) some > >>>>IDE devices or SCSI discs and so on. > >>>> > >>>>Here's the beta of the container. Currently this only allows to > >>>>hide the _character_ devices only from the living tasks. To play > >>>>with it you just create the container like this > >>>> > >>>> # mount -t container none /cont/devs -o devices > >>>> # mkdir /cont/devs/0 > >>>> > >>>>it will have two specific files > >>>> > >>>> # ls /cont/devs > >>>>devices.block devices.char notify_on_release releasable release_agent tasks > >>>> > >>>>then move a task into it > >>>> > >>>> # /bin/echo -n $$ > /cont/devs/0/tasks > >>>> > >>>>after this you won't be able to read from even /dev/zero > >>>> > >>>> # hexdump /dev/zero > >>>>hexdump: /dev/zero: No such device or address > >>>>hexdump: /dev/zero: Bad file descriptor > >>>> > >>>>meanwhile from another ssh session you will. You may allow access > >>>>to /dev/zero like this > >>>> > >>>> # /bin/echo -n '+1:5' > /cont/devs/0/devices.char > >>>> > >>>>More generally, the '+<major>:<minor>' string grants access to > >>>>some device, and '-<major>:<minor>' disables one. > >>>> > >>>>The TODO list now looks like this: > >>>>* add the block devices support :) don't know how to make it yet; > >>>>* make /proc/devices show relevant info depending on who is > >>>> reading it. currently even if major 1 is disabled for task, > >>>> it will be listed in this file; > >>>>* make it possible to enable/disable not just individual major:minor > >>>> pair, but something more flexible, e.g. major:* for all minors > >>>> for given major or major:m1-m2 for …
creator: serue
date: 2007-09-24T16:53:07-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Eric W. Biederman wrote: > Pavel Emelyanov <xemul@openvz.org> writes: > >> Hi. >> >> At KS we have pointed out the need in some container, that allows >> to limit the visibility of some devices to task within it. I.e. >> allow for /dev/null, /dev/zero etc, but disable (by default) some >> IDE devices or SCSI discs and so on. > > NAK > > We do not want a control group subsystem for this. > > For the short term we can just drop CAP_SYS_MKNOD. > > For the long term we need a device namespace for application > migration, so they can continue to use devices with the same > major+minor number pair after the migration event. Things like Oh! Can you provide us an example when after the migration some device's major+minor pair change on the same device? > ensuring a call to stat on a given file before and after the migration > return the exact same information sounds compelling. So I don't think > this is even strictly limited to virtual devices anymore. How many > applications are there out there that memorize the stat data on a file > and so they can detect if it has changed? > > If we need something between those two it may make sense to enhance > the LSM or perhaps introduce an alternate set security hooks. Still > if we are going to need a full device namespace that may be a little > much. > > Eric > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-09-25T07:48:03-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: On 9/24/07, Pavel Emelyanov <xemul@openvz.org> wrote: > > # /bin/echo -n '+1:5' > /cont/devs/0/devices.char > > More generally, the '+<major>:<minor>' string grants access to > some device, and '-<major>:<minor>' disables one. How about a more forward-compatible API: <major>:<minor>=<permissions>[,<remapped_major>:<remapped_minor>] This would allow you the control the access that each cgroup has to a given device (permissions of 0 indicates that the device isn't even visible, i.e. the same as your "-<major>:<minor>" operation. For now specifying the (optional) remapping could just fail, but at least the API would be defined. Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-09-25T07:53:11-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Paul Menage wrote: > On 9/24/07, Pavel Emelyanov <xemul@openvz.org> wrote: >> # /bin/echo -n '+1:5' > /cont/devs/0/devices.char >> >> More generally, the '+<major>:<minor>' string grants access to >> some device, and '-<major>:<minor>' disables one. > > How about a more forward-compatible API: > > <major>:<minor>=<permissions>[,<remapped_major>:<remapped_minor>] I'd rather make it look like <major>:<mino>[:<permissions>][:<map_major>:<map_minor>] where <permissions>:=[r-][w-] and NULL means rw this would keep current API compatible and allow it for extension. > This would allow you the control the access that each cgroup has to a > given device (permissions of 0 indicates that the device isn't even > visible, i.e. the same as your "-<major>:<minor>" operation. For now > specifying the (optional) remapping could just fail, but at least the > API would be defined. > > Paul > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-09-25T08:00:07-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Pavel Emelyanov wrote: > Paul Menage wrote: >> On 9/24/07, Pavel Emelyanov <xemul@openvz.org> wrote: >>> # /bin/echo -n '+1:5' > /cont/devs/0/devices.char >>> >>> More generally, the '+<major>:<minor>' string grants access to >>> some device, and '-<major>:<minor>' disables one. >> How about a more forward-compatible API: >> >> <major>:<minor>=<permissions>[,<remapped_major>:<remapped_minor>] > > I'd rather make it look like > > <major>:<mino>[:<permissions>][:<map_major>:<map_minor>] > > where > > <permissions>:=[r-][w-] and NULL means rw bah. numeric mode are better. C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-09-25T11:20:31-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Hello Eric ! Eric W. Biederman wrote: > Pavel Emelyanov <xemul@openvz.org> writes: > >> At KS we have pointed out the need in some container, that allows >> to limit the visibility of some devices to task within it. I.e. >> allow for /dev/null, /dev/zero etc, but disable (by default) some >> IDE devices or SCSI discs and so on. > > NAK > > We do not want a control group subsystem for this. we will need one way to configure the list of available devices from user space. Any proposal ? > For the short term we can just drop CAP_SYS_MKNOD. Sure. Pavel is working on something mid-term ;) > For the long term we need a device namespace for application > migration, so they can continue to use devices with the same > major+minor number pair after the migration event. Hmm, yes. I can imagine that for some big database application using raw devices but it only means that the same device must be present upon restart. I don't see any identifier virtualization issues. > Things like > ensuring a call to stat on a given file before and after the migration > return the exact same information sounds compelling. So I don't think > this is even strictly limited to virtual devices anymore. How many > applications are there out there that memorize the stat data on a file > and so they can detect if it has changed? that we need to support of course, otherwise we would break things like tail. > If we need something between those two it may make sense to enhance > the LSM or perhaps introduce an alternate set security hooks. Still > if we are going to need a full device namespace that may be a little > much. serge's implementation using security hooks should help us choose the right approach. Thanks ! C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-09-25T12:25:24-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Pavel Emelyanov <xemul@openvz.org> writes: > > Oh! Can you provide us an example when after the migration some > device's major+minor pair change on the same device? SCSI disks on a SAN. Network accessible block devices. All kinds of logical/virtual devices like ttys, the loop device, and ramdisks. It isn't especially frequent that something cares, but fundamentally the same issues apply. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-09-25T13:30:44-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Cedric Le Goater <clg@fr.ibm.com> writes: > Hello Eric ! > > Eric W. Biederman wrote: >> Pavel Emelyanov <xemul@openvz.org> writes: >> >>> At KS we have pointed out the need in some container, that allows >>> to limit the visibility of some devices to task within it. I.e. >>> allow for /dev/null, /dev/zero etc, but disable (by default) some >>> IDE devices or SCSI discs and so on. >> >> NAK >> >> We do not want a control group subsystem for this. > > we will need one way to configure the list of available devices from > user space. Any proposal ? Proposal 1/2. From the kernel side we have. dev_ns_add(kdev_t cur_dev, struct dev_ns *target_ns, kdev_t target_kdev) Which looks up the device and add it to the hash tables in the proper device namespace, and fires off the appropriate hotplug events. I guess the easy user space interface would be: echo <device_ns_pid>:<major>:<minor> > /sys/block/ram0/dev Although I suspect that we want some restrictions on what combinations of major and minor numbers are valid. Despite the fact that my gut says writeable sysfs files were a bad idea. Since we have them my gut says sysfs the filesystem of devices is where we need the control files for devices. >> For the short term we can just drop CAP_SYS_MKNOD. > > Sure. Pavel is working on something mid-term ;) Well. I don't think midterm is mergeable, I do think it is good for conversation though. I also don't see why what Pavel is doing can't be implemented as a device namespace. >> For the long term we need a device namespace for application >> migration, so they can continue to use devices with the same >> major+minor number pair after the migration event. > > Hmm, yes. I can imagine that for some big database application using > raw devices but it only means that the same device must be present > upon restart. I don't see any identifier virtualization issues. Well there is the classic one. You are migrating to a machine which is using that major+minor number for a different device al…
creator: ebiederm
date: 2007-09-25T13:43:53-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: On Tue, 2007-09-25 at 07:30 -0600, Eric W. Biederman wrote: > Pavel Emelyanov <xemul@openvz.org> writes: > > > > Oh! Can you provide us an example when after the migration some > > device's major+minor pair change on the same device? > > SCSI disks on a SAN. Network accessible block devices. > All kinds of logical/virtual devices like ttys, the loop device, and > ramdisks. > > It isn't especially frequent that something cares, but fundamentally > the same issues apply. To be clear, this just covers cases where an application has _internalized_ the device number, right? Most applications should be pretty happy with the devices having persistent device names across a restart, and we can do that with udev and no kernel patching. -- Dave _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Dave Hansen
date: 2007-09-26T15:36:12-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: Dave Hansen <haveblue@us.ibm.com> writes: > On Tue, 2007-09-25 at 07:30 -0600, Eric W. Biederman wrote: >> Pavel Emelyanov <xemul@openvz.org> writes: >> > >> > Oh! Can you provide us an example when after the migration some >> > device's major+minor pair change on the same device? >> >> SCSI disks on a SAN. Network accessible block devices. >> All kinds of logical/virtual devices like ttys, the loop device, and >> ramdisks. >> >> It isn't especially frequent that something cares, but fundamentally >> the same issues apply. > > To be clear, this just covers cases where an application has > _internalized_ the device number, right? Also cases where you want to call mknod in the container. > Most applications should be pretty happy with the devices having > persistent device names across a restart, and we can do that with udev > and no kernel patching. Yes. But the applications that do internalize stat data from files aren't that uncommon. git, and backup software etc. There is also a fair bit of work that is needed to get sysfs and the hotplug events isolated, when we start allowing mknod etc. Basically if I figure if we are going to deal with this we need to handle the entire problem because these pieces are user visible. I don't think it is a great priority. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-09-26T19:09:46-00:00

Re: [RFC][PATCH] Devices visibility container
type: item
description: On Wed, 2007-09-26 at 13:09 -0600, Eric W. Biederman wrote: > Dave Hansen <haveblue@us.ibm.com> writes: > > > On Tue, 2007-09-25 at 07:30 -0600, Eric W. Biederman wrote: > >> Pavel Emelyanov <xemul@openvz.org> writes: > >> > > >> > Oh! Can you provide us an example when after the migration some > >> > device's major+minor pair change on the same device? > >> > >> SCSI disks on a SAN. Network accessible block devices. > >> All kinds of logical/virtual devices like ttys, the loop device, and > >> ramdisks. > >> > >> It isn't especially frequent that something cares, but fundamentally > >> the same issues apply. > > > > To be clear, this just covers cases where an application has > > _internalized_ the device number, right? > > Also cases where you want to call mknod in the container. mknod of device files only, yeah. > > Most applications should be pretty happy with the devices having > > persistent device names across a restart, and we can do that with udev > > and no kernel patching. > > Yes. But the applications that do internalize stat data from files > aren't that uncommon. git, and backup software etc. > > There is also a fair bit of work that is needed to get sysfs > and the hotplug events isolated, when we start allowing mknod etc. > > Basically if I figure if we are going to deal with this we need to handle > the entire problem because these pieces are user visible. I don't > think it is a great priority. Exactly. We have to allow mknod before any of this gets interesting in the least. -- Dave _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Dave Hansen
date: 2007-09-27T15:46:45-00:00