This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Tuesday 11 October 2011 15:05:37 Serge E. Hallyn wrote: > Quoting Mike Frysinger (vapier@gentoo.org): > > On Tuesday 11 October 2011 13:15:37 Serge E. Hallyn wrote: > > > I'm not sure of the best way to fix this in a way palatable to glibc. > > > Follow the /proc/self/fd/N symlink? Update the manpages to say the > > > devpts used must be mounted under /dev/pts by the caller? (Caller > > > would need privilege, but can fork+unshare+bind-mount). > > > > doesn't the caller already need privs to chroot in the first place ? > > The caller hasn't chrooted (if he had, then glibc would find /dev/pts/0 :). sorry, i thought you were talking the other way around. code running inside of the chroot was missing the devpts mount on /dev/pts/. > > it's been this way for years which means i would have expected all > > relevant code to have accounted for this already (not saying that it > > wouldn't be nice to have things "just work" when possible) ... > > It rarely shows up in libvirt, but that's purely by accident since > /dev/pts/0 is usually in use, and if it isn't the driver creates a pty > on the host first, which will take /dev/pts/0. So you have to do > something to keep /dev/pts/0 from being re-used on the host, but it's > doable (and has been done and reported). hmm, maybe i need to read more about pty's and devpts, but this doesn't sound right. you should have "devpts" mounted in /dev/pts/ outside of the chroot, and inside of the chroot. and the way Linux implements the "devpts" pseudo fs, there's only 1 actual instance, so all mounts will be in sync automatically. thus /dev/pts/# will be the same pty inside of the chroot as well as outside. maybe there's magic behavior going on with containers ? > So if the answer is just don't do that, then the manpage should be updated, > right? The problem is that unless you look at the implementation, you have > no idea why grantpt shouldn't work on an fd opened in another ptsns. glibc doesn't maintain linux man pages ;) > It'd still be neat if we could fix it for real, but the only way I can > think of is to follow /proc/self/fd/<fd>, and while i've not thought it > through i have a feeling that's not a good idea. looking up symlinks instead of simply asking the kernel via an ioctl sounds like a step backwards ... -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |