On 03/15/2013 07:21 PM, Serge Hallyn wrote: > Quoting Glauber Costa (glommer@xxxxxxxxxxxxx): >> On 03/15/2013 06:00 PM, Serge Hallyn wrote: >>> Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >>>> Glauber Costa <glommer@xxxxxxxxxxxxx> writes: >>>> >>>>> Hi, >>>>> >>>>> devpts mounts in user namespaces is queued for 3.9. However, while playing >>>>> with it I found it to be less than ideal. Although it could possibly work >>>>> with custom software that can be made to point to /dev/pts/ptmx, a few things >>>>> prevent it from working correctly for people that, like us, are booting full >>>>> distributions. >>>> >>>> Full distributions that have not been modified to be minimally container >>>> aware. >>> >>> Right, in fact in this case it doesn't need to be minimally container >>> aware, you just create the bind mount yourself and init just needs to >>> accept that it shouldn't touch it. >>> >> >> Well, what if it doesn't? >> >> At least in the system I am using, centos6, udev mounts a tmpfs in a >> temporary location, and then mount --move this to /dev. This is now >> empty, and devpts will be mounted ontop of that. > > This also messes up your /dev/ttyN setup right? How are you handling > that? > very simple: udev will just mknod everything back, so let him! >> Let me reverse the question: If you bind mount /dev/pts and then udev >> never touches it, etc, does my solution affects that in anyway? The way >> I see it, we just become more capable of running legacy system without >> giving nothing in return aside from code. And it is not even an >> extremely complex code. > > Right - I don't object to your patch, I just wanted to see if you and > Eric could agree on which one to use. After that I'll do a closer > review - but on first look it looked good to me. > As I said, as far as the specific part of the puzzle concerning the /dev/ptmx to /dev/pts/ptmx mapping, I am fine with whatever works. >>>>> One of the problems that I am addressing in here is that we are disallowing >>>>> mknod in usernamespaces. Although I understand the motivation for that, I >>>>> believe that to be too restrictive, specially because we already control access >>>>> to the files separately. There should be no harm in mknod'ing something per se, >>>>> if manipulating it is forbidden. >>>> >>>> mknod in userspace needs to be a separate patchset. There is no need to >>>> solve mknod in userspace to solve devpts. >>>> >>>> >>>>> Last, /dev/ptmx will still always be the global ptmx device. We need to somehow >>>>> link it to our namespaces'. My proposal is to multiplex it and return the >>>>> correct "root ptmx" depending on which userns is reading that device. >>>> >>>> Doable. I still strongly prefer my version of having /dev/ptmx act like >>>> a link to /dev/pts/ptmx. Letting the mount namespace control it. >>> >>> Right, Glauber have you seen this patch? Eric did already solve this. >>> (And again that's a nice safeguard, but it shouldn't be necessary) >>> >> No. Where was that sent to? >> >> If you can point me to it, I am of course willing to test it. If it >> solves my problem (the description suggests that there is high >> probability), then I have no particular attachments to my specific solution. > > Well shoot, I can't find it right now. Not even in Eric's git tree. > IIRC upon lookup of /dev/pts it tried to find $rootfs/dev/pts/ptmx > and open that instead. > Which gives a very good explanation about why haven't I seen it =) Eric ? 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
