Created attachment 382883 [details] container definition Description of problem: See summary Version-Release number of selected component (if applicable): kernel-PAE-2.6.32.2-18.fc13.i686 How reproducible: Always Steps to Reproduce: 1. yum install libvirt lxc mach 2. Put the following in ~/.machrc: config['defaultroot'] = 'fedora-development-i386-core' 3. mach setup minimal 4. mach yum install coreutils shadow-utils strace nullmodem 5. mach chroot 6. useradd test 7. Exit the chroot 8. Download attached file ptybug.xml 9. virsh --connect lxc:/// define ptybug.xml 10. virsh --connect lxc:/// start ptybug 11. virsh --connect lxc:/// console ptybug 12. su - test 13. strace -f -e trace=none nullmodem -F 0 1 Actual results: nullmodem 0.0.6 (compiled Jul 27 2009 01:51:15) Opening port 0 Opening port 1 Reopening, 0, port 0 Process 27 attached Process 26 suspended Process 26 resumed Process 27 detached --- SIGCHLD (Child exited) @ 0 (0) --- Open pty failed : Exec format error Reopening, 1, port 1 Process 28 attached Process 26 suspended Process 26 resumed Process 28 detached --- SIGCHLD (Child exited) @ 0 (0) --- Open pty failed : Exec format error Process 29 attached Process 26 suspended Process 26 resumed Process 29 detached --- SIGCHLD (Child exited) @ 0 (0) --- Open pty failed : Exec format error Process 30 attached Process 26 suspended Process 26 resumed Process 30 detached --- SIGCHLD (Child exited) @ 0 (0) --- Open pty failed : Exec format error Expected results: (taken from run outside the lxc container) nullmodem 0.0.6 (compiled Jul 27 2009 01:51:15) Opening port 0 Opening port 1 Reopening, 0, port 0 Reopening, 1, port 1 Additional info: I used libvirt instead of the lxc command-line tools because of bug 554145 and bug 554164
(In reply to comment #0) > > 9. virsh --connect lxc:/// define ptybug.xml > 10. virsh --connect lxc:/// start ptybug > 11. virsh --connect lxc:/// console ptybug > 12. su - test this fails with su: incorrect password# id uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:virtd_t:s0-s0:c0.c1023 and I don't know how to fix su. > 13. strace -f -e trace=none nullmodem -F 0 1 if I do the above without su, it fails with EPERM instead of ENOEXEC. And, it fails the same way without strace too. Hmm. According to strace, chown32("/dev/pts/1", 0, 5) returns EPERM and then nullmodem reports "Open pty failed: Permission denied". bash-4.1# touch /tmp/xxx bash-4.1# ls -l /tmp/xxx -rw-r--r--. 1 root root 0 Mar 5 13:36 /tmp/xxx bash-4.1# chown test:test /tmp/xxx chown: changing ownership of `/tmp/xxx': Operation not permitted So. it is not clear to me how to reproduce the problem. And sorry, I do not know how to setup this container environment correctly. Could you please confirm nullmodem does work without strace? If yes, please do "strace -ff -o log" and show the resulting log.* files. --------------------------------------------------------------------- But. Please note that, since you run "strace -f" under user "test", any setuid binary will not get the root privs. Probably this explains the problem, afaics nullmodem needs the help of /usr/libexec/pt_chown.
I took the Fedora 13 choice when rawhide was forked, and unfortunately LXC is unusable for me on F13 at the moment due to bug 570708. I will come back to this bug after that bug is addressed.
(In reply to comment #1) > (In reply to comment #0) > > > > 9. virsh --connect lxc:/// define ptybug.xml > > 10. virsh --connect lxc:/// start ptybug > > 11. virsh --connect lxc:/// console ptybug > > 12. su - test > > this fails with > > su: incorrect password# id > uid=0(root) gid=0(root) groups=0(root) > context=system_u:system_r:virtd_t:s0-s0:c0.c1023 > > and I don't know how to fix su. Hmm, strange. I don't encounter this error. Maybe an SELinux issue? (SELinux is disabled on my machine.) > > 13. strace -f -e trace=none nullmodem -F 0 1 > > if I do the above without su, it fails with EPERM instead > of ENOEXEC. This bug only occurs when you run as non-root. EPERM might also be an SELinux issue? > Could you please confirm nullmodem does work without strace? Yes, reconfirmed. > If yes, please do "strace -ff -o log" and show the resulting log.* > files. I will attach them momentarily. > > --------------------------------------------------------------------- > But. Please note that, since you run "strace -f" under user "test", > any setuid binary will not get the root privs. Probably this explains > the problem, afaics nullmodem needs the help of /usr/libexec/pt_chown. No, it doesn't explain the problem, because nullmodem does work as user test without strace. It also works when run under strace, but not inside LXC.
Created attachment 399815 [details] logs from strace
(In reply to comment #3) > (In reply to comment #1) > > --------------------------------------------------------------------- > > But. Please note that, since you run "strace -f" under user "test", > > any setuid binary will not get the root privs. Probably this explains > > the problem, afaics nullmodem needs the help of /usr/libexec/pt_chown. > > No, it doesn't explain the problem, it does ;) please look into the logs. Like I expected, nullmodem failed to chown32("/dev/pts/1", 500, 5) (see log.30) and it spawns the suid pt_chown to do this. But since this all runs under strace, pt_chown starts without root privileges and therefore it can't help. > because nullmodem does work as user test > without strace. See above. Say, /bin/mount, won't work under strace too. Any suid app won't work, this is correct. > It also works when run under strace, but not inside LXC. So the question is: how to setup the devpts magic properly inside LXC so that pt_exec is not needed. But I know nothing about this. To be absolutely sure, please do "chmod u-s /usr/libexec/pt_chown" _inside_ lxc, then run nullmodem without strace.
(In reply to comment #5) > So the question is: how to setup the devpts magic properly > inside LXC so that pt_exec is not needed. Ah, yes, you're right. Sorry. > To be absolutely sure, please do "chmod u-s /usr/libexec/pt_chown" > _inside_ lxc, then run nullmodem without strace. Indeed, it doesn't work when I do that, as you expected. After some work, I found out that the problem is very similar to the one described in bug 506219. Summary: /dev/pts needs to be mounted with mount options gid=5,mode=620. Since libvirt is responsible for mounting the private /dev/pts (and nothing else changes the mount options) I've changed the component of this bug to libvirt. Please reassign this bug to an appropriate owner, as I don't have privileges to do that.
This bug still exists in libvirt-0.8.3-2.fc14.i686 on Fedora 14 (see comment#6 above for how to fix).
This is fixed in libvirt GIT now http://libvirt.org/git/?p=libvirt.git;a=commit;h=08fb2a9ce855c6ed1042e451fb4dfc6664a77d64
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
F14 is EOL, please reopen if this is still relevant in a more recent fedora.