Bug 228102

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