Quoting Janne Karhunen (janne.karhunen@xxxxxxxxx): > On Fri, Mar 15, 2013 at 4:20 PM, Serge Hallyn <serge.hallyn@xxxxxxxxxx> wrote: > > >> We will do that by marking the mount as MNT_NODEV_NS instead of > >> MNT_NODEV. This is because if the mount operation explicitly asked for > >> nodev, we ought to respect it. MNT_NODEV_NS will forbid accesses if the > >> task is not on a device cgroup. If it is, we will rely on the control > >> rules in devcg to intermediate the access an tell us what those tasks > >> can or cannot do. > > > > 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. > 'Device namespace' Cells whitepaper [1] talks about seems to be > saying they also implemented a callback for some drivers (only oh, thanks, haven't read that one, will have to. > init_ns accessible ioctl?) to support their 'foreground/background' > use case. While this is certainly one use case, it's certainly nothing > generic. > > 1. http://www.cs.columbia.edu/~nieh/pubs/sosp2011_cells.pdf > > > -- > Janne _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
