Bug 228102 - lspp: newrole doesn't work on serial consoles
lspp: newrole doesn't work on serial consoles
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: policycoreutils (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: OtherQA
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-02-09 18:29 EST by Linda Knippers
Modified: 2009-06-19 10:58 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2007-0543
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 13:03:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A patch to newrole that adds O_NONBLOCK to the tty opens. (814 bytes, application/octet-stream)
2007-02-09 18:29 EST, Linda Knippers
no flags Details
updated patch that turns off O_NONBLOCK (1.21 KB, patch)
2007-02-20 13:35 EST, Linda Knippers
no flags Details | Diff

  None (edit)
Description Linda Knippers 2007-02-09 18:29:28 EST
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.
Comment 1 Linda Knippers 2007-02-09 18:29:28 EST
Created attachment 147823 [details]
A patch to newrole that adds O_NONBLOCK to the tty opens.
Comment 2 Daniel Walsh 2007-02-12 10:32:04 EST
Added patch to policycoreutils-1.33.12-4
Comment 3 George C. Wilson 2007-02-12 21:02:44 EST
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.
Comment 4 Stephen Smalley 2007-02-20 12:55:43 EST
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.
Comment 5 Linda Knippers 2007-02-20 13:00:37 EST
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.  
Comment 6 Linda Knippers 2007-02-20 13:35:39 EST
Created attachment 148431 [details]
updated patch that turns off O_NONBLOCK
Comment 7 Linda Knippers 2007-02-20 13:38:13 EST
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.
Comment 9 Daniel Walsh 2007-02-20 16:59:18 EST
Updated in policycoreutils-1.33.12-6
Comment 10 Stephen Smalley 2007-02-21 08:27:12 EST
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:
#

Comment 11 Linda Knippers 2007-02-21 10:17:16 EST
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?
Comment 12 Daniel Walsh 2007-02-21 10:45:37 EST
Probably a kernel problem.  Maybe eparis would have an idea.
Comment 13 Stephen Smalley 2007-02-21 10:57:51 EST
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
Comment 14 Linda Knippers 2007-02-21 11:20:45 EST
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.
Comment 15 Stephen Smalley 2007-02-21 12:01:14 EST
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?
Comment 16 Linda Knippers 2007-02-21 12:15:27 EST
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.
Comment 17 Stephen Smalley 2007-02-22 08:18:23 EST
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.
Comment 18 Linda Knippers 2007-02-22 09:57:42 EST
Ok, I've submitted the path to the selinux list.  Thanks.
Comment 21 Linda Knippers 2007-04-04 22:13:19 EDT
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. 
Comment 25 errata-xmlrpc 2007-11-07 13:03:57 EST
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

Note You need to log in before you can comment on or make changes to this bug.