Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > Glauber Costa <glommer@xxxxxxxxxxxxx> writes: ... > > What it a /dev/ptmx already exist? will it use it? That would be bad, > > since that /dev/ptmx could be a host-side one. I actually believe > > linking to $rootfs/dev/pts/ptmx is more robust than my solution against > > remounts. So provided it can guarantee that the ptmx is not ever the > > root ptmx, I would ack that. > > For those playing with udev, especially older udev where udev is still > udev and creates devices you can use the following udev rule to create > the pts/ptmx symlink. > > KERNEL=="ptmx" NAME:="pts/ptmx" SYMLINK="ptmx" > > Before we do anything clever in the kernel it is definitely worth seeing > how far we can take that little udev rule. Before it was decided that it was ok to modify core packages to accomodate containers, we had to install (non-standard) init jobs to detect it was in a container and if so modify some behavior - for instance to bind-mount a smaller /lib/init/fstab so that mountall wouldn't try to mount some things. That way the rootfs had to be updated to run in a container, but could then still be used as a rootfs for non-containers. ... > As much as I hate the notion I suspect for most of device management > what we want is to act like devtmpfs, and run all of the device node > creation etc outside of the container (possibly even with bind mounts). So you mean a task which is unprivileged on the host, privileged wrt the container, and on host fs namespace, which bind mounts the host /dev files into the container? > Acting like devtmpfs should be something that is possible with no kernel > changes. Whereas allowing unprivileged processes to create device > nodes probably has issues I haven't thought of yet. Not sure what 'acting like devtmpfs' means (especially in contrast to acting like udev) - maybe i need to go look at the code. -serge -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
