Serge Hallyn <serge.hallyn@xxxxxxxxxx> writes: > 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. That little udev rule could be one of those trivial modifications. > ... > >> 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? That would be the implementation. Although you could potentialy have something privileged on the host doing the work from outside of 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. devtmpfs is a magic kernel thread and instance of tmpfs that calls mknod based on the default device name and permission policy that is new in the kernel. Which means that any distro that can use devmpts has no problems with something else calling mknod and creating the devices. And the initrd is expected to have mounted devtmpfs last I looked. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
