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. Although it can be changed, of course, it is very likely to be due to its age. And that is not even the oldest distribution around. Now, both operations are totally valid inside namespaces. Both mount --move and mounting tmpfs. If there were any way to identify those specific mounts and block them, I would be fine. But so far, given my understanding, you guys are asking me to either go convince people to change their very old stable distributions, or complicate deployment with all sorts of special cases for them. I fully agree that the behavior you describe is the best behavior if it can be done, but I am not satisfied with the answer that legacy distributions should somehow be adapted. 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. >>> 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. -- 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
