Description of problem: I'm running the rhel5 rc1 with the latest mls policy from Dan's repo in a system with a serial console. When I log in on the console and run newrole, it hangs when it reopens the tty. It doesn't matter if the system is in enforcing mode or not. I can reproduce the hang with a little test program that opens the tty device, in my case its "/dev/ttyS1". If I change all the opens in newrole to have the O_NONBLOCK flag, it works. Version-Release number of selected component (if applicable): RHEL5 rc1 with mls policy selinux-policy-mls-2.4.6-32.el5 although the behavior is probably the same with strict policy. How reproducible: very Steps to Reproduce: 1.Install a system with a serial console 2.log in and run newrole (doesn't matter if you're changing levels or roles, it will hang 3. Actual results: Newrole hangs after taking the password and before execing the shell. Its hanging in the open that's in relabel_tty. Expected results: It should exec a new shell Additional info: I little patch is attached but I don't know if this is what we really want to do, not being a tty expert. newrole works fine on ptys.
Created attachment 147823 [details] A patch to newrole that adds O_NONBLOCK to the tty opens.
Added patch to policycoreutils-1.33.12-4
Confirmed: We're seeing this as well. I tried both agetty and mgetty using a non-console tty (obviously added to securetty) on an x86_64 with the same effect. I don't want to reconfigure my ppc64 partition right now to get a virtual serial port, but I'd be surprised if I didn't see it there, too. Your patch is likely the correct one unless somebody has a reason we need the blocking behavior and there is something we can do to get it to work on serial terminals. Upgraded to policycoreutils-1.33.12-4, which fixed the problem. Thank you, Linda and Dan.
I think that the patch could have side effects on the newrole'd shell and programs run from it, as they may not normally expect their stdin to be non-blocking by default. I would suggest opening with O_NONBLOCK and then clearing it via fcntl in the child before exec'ing the shell as a possible alternative. Someone familiar with shell internals (e.g. bash maintainer) might have more insight.
This is true. I just verified that 'more' doesn't work, for example. I'd still like to understand why the open is hanging. I can reproduce it with a little test program.
Created attachment 148431 [details] updated patch that turns off O_NONBLOCK
My comments about the patch in #6 didn't go in. The patch implements Stephen's suggestion and basically does what agetty does. I'm still not sure why the open hangs though.
Updated in policycoreutils-1.33.12-6
I can't reproduce the bug here on a serial console (with upstream newrole, no patches applied). # tty /dev/ttyS0 # grep ttyS0 /etc/inittab co:2345:respawn:/sbin/agetty ttyS0 115200 # ./newrole -r sysadm_r Authenticating root. Password: #
Stephen, what kernel are you running and what hardware? On my ia64 box, an open on the serial console blocks in uart_open. I can reproduce it outside of newrole. [root@cert-i4 ~]# tty /dev/ttyS1 [root@cert-i4 ~]# grep ttyS1 /etc/inittab co:2345:respawn:/sbin/agetty ttyS1 9600 vt100-nav [root@cert-i4 ~]# ps -l |grep testopen 0 S 0 1924 1883 0 75 0 - 206 uart_o ttyS1 00:00:00 testopen I think uart_open is in generic serial port code and George is seeing it on x86_64 so it seems like a general problem. I'd really like to understand why the open blocks. Patching newrole seems like a workaround. Dan, anyone at Red Hat familiar with the serial port code?
Probably a kernel problem. Maybe eparis would have an idea.
x86, a variety of kernels, serial port is connected to a Avocent CPS1610. That is our testbed set up, and we've long used newrole on the serial console there. But I notice that you have "vt100" in your inittab. Per agetty man page: For a hard-wired line or a console tty: /sbin/agetty 9600 ttyS1 For a directly connected terminal without proper carriage detect wiring: (try this if your terminal just sleeps instead of giving you a password: prompt.) /sbin/agetty -L 9600 ttyS1 vt100
I'm running the stock inittab so that's the line that kudzu up in. I think all its doing is setting my TERM variable. I took the "vt100-nav" out and I get the same behavior, only this time my TERM is set to 'linux'. What's interesting is that I logged off while my test program was still blocked and I got this: uart_close: bad serial port count; tty->count is 1, state->count is 2 I suppose that's because the open never completed. BTW, my system doesn't actually have a physical terminal attached. Its a virtual serial console through a management port. I'm not sure what George's configuration is.
Did you try with the -L option to agetty as per the man page? Also, have you confirmed that your new patch (open with O_NONBLOCK then clear it via fcntl) enables you to newrole on that console and to run more as expected?
I did not try the -L option because it didn't seem to match my symptoms. I never had a problem getting the login or passwd prompts. However, adding -L fixes the problem, or is at least a better workaround. Thanks for the suggestion. And yes, I tested the second patch with newrole and more since that's why I made the second patch in the first place. I guess that was in the comment that failed to go in with the patch. At this point though, I don't think we need the patch.
Despite the fact that -L solves the problem for you, I'm inclined to take your second patch upstream, as it does seem that newrole should sanely handle this case and not block on a serial port. As newrole only opens the tty for the purposes of relabeling it and creating descriptors suitable for the child shell, opening O_NONBLOCK is reasonable for newrole itself, and then clearing O_NONBLOCK should avoid problems with the child shell. So post your patch to the selinux list please.
Ok, I've submitted the path to the selinux list. Thanks.
We just realized that this fix hasn't made its way into Steve's LSPP repo. We need an official build of this package please. I've been running with the one in Dan's repo since it was first posted and it seems fine.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0543.html