Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 621062 - Service scripts break terminal settings on SELinux system
Summary: Service scripts break terminal settings on SELinux system
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: AMD64 Linux
: Normal minor (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-06 18:33 UTC by Andriy Utkin (RETIRED)
Modified: 2017-10-29 14:24 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
newrole.strace.gz (newrole.strace.gz,116.10 KB, text/plain)
2017-06-09 23:45 UTC, Andriy Utkin (RETIRED)
Details
Patch to clear nonblock flag on stdin before exit (nonblock.patch,478 bytes, patch)
2017-07-02 03:33 UTC, dwfreed
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Utkin (RETIRED) gentoo-dev 2017-06-06 18:33:58 UTC
After any call to any openrc /etc/init.d scripts from shell with SELinux sysadm_r role, terminal session is broken, not being able to request user's input by such means as read(1). What I observe is that stdin, stdout and stderr are set to non-blocking mode.

I don't know any workaround for this besides opening a new privileged shell session.

Reproducible: Always

Steps to Reproduce:
0. Use a SELinux-enabled system. Doesn't matter whether mode is permissive or enforcing.
1. Switch to superuser in your shell with command "sudo -s -r sysadm_r -t sysadm_t". With simply "sudo -s" the bug does NOT reproduce.
2. Run any service command, e.g. "service sshd status".
3. Run "read" to let shell prompt for user input.
Actual Results:  
j@hostname ~ $ sudo -s -r sysadm_r -t sysadm_t
hostname j # service sshd status
Authenticating root.
 * status: started
hostname j # read
bash: read: read error: 0: Resource temporarily unavailable
hostname j #

Expected Results:  
Last command, "read", would prompt for user input.

Checking /proc/self/fdinfo/{0,1,2} reveals the change in "flags" from 0100002 to 0104002.


Working scenario with "sudo -s":

j@hostname ~ $ cat /proc/self/fdinfo/0
pos:    0
flags:  0100002
mnt_id: 18
j@hostname ~ $ sudo -s
hostname j # cat /proc/self/fdinfo/0
pos:    0
flags:  0100002
mnt_id: 18
hostname j # service sshd status
 * status: started
hostname j # read
asdf
hostname j # exit


Broken scenario:


j@hostname ~ $ cat /proc/self/fdinfo/0
pos:    0
flags:  0100002
mnt_id: 18
j@hostname ~ $ sudo -s -r sysadm_r -t sysadm_t
hostname j # cat /proc/self/fdinfo/0
pos:    0
flags:  0100002
mnt_id: 18
hostname j # service sshd status
Authenticating root.
 * status: started
hostname j # cat /proc/self/fdinfo/0
pos:    0
flags:  0104002
mnt_id: 18
hostname j # read
bash: read: read error: 0: Resource temporarily unavailable
hostname j #
Comment 1 William Hubbs gentoo-dev 2017-06-07 15:36:28 UTC
@selinux:
Do you know what is going on here?

Thanks,

William
Comment 2 Jason Zaman gentoo-dev 2017-06-08 09:55:07 UTC
(In reply to Andrey Utkin from comment #0)
> Broken scenario:
> j@hostname ~ $ cat /proc/self/fdinfo/0
> pos:    0
> flags:  0100002
> mnt_id: 18
> j@hostname ~ $ sudo -s -r sysadm_r -t sysadm_t
> hostname j # cat /proc/self/fdinfo/0
> pos:    0
> flags:  0100002
> mnt_id: 18
> hostname j # service sshd status
> Authenticating root.
>  * status: started
> hostname j # cat /proc/self/fdinfo/0
> pos:    0
> flags:  0104002
> mnt_id: 18
> hostname j # read
> bash: read: read error: 0: Resource temporarily unavailable
> hostname j #

I cant repro this issue.
can you try a few variations to see if they work:

/etc/init.d/sshd status instead of service ...
rc-service sshd status instead of service ...
run_init /etc/init.d/sshd status instead of status sshd...

putting this in your sudoers so it does the -r -t automatically:
%wheel ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL

comment out the rootok line in /etc/pam.d/run_init so it asks for password then try run_init in front of all the variations above

and if you use newrole+su instead of sudo it works?
$ newrole -r sysadm_r
$ su 

and what version of sudo? im on app-admin/sudo-1.8.20_p2

hopefully you find some combination that works then we can narrow things down or find something i can repro.
Comment 3 Andriy Utkin (RETIRED) gentoo-dev 2017-06-09 23:42:54 UTC
Thanks for looking into this.

First, some info which I should have put into bugreport ifself.

My workstation used
sys-apps/policycoreutils-2.6-r1
app-admin/sudo-1.8.20
sys-apps/openrc-0.26.2

Today I have updated sudo and openrc before re-testing this all:
app-admin/sudo-1.8.20_p2:0
sys-apps/openrc-0.27.1:0

I may try =sys-apps/policycoreutils-9999 if that may help. Which version do you run Jason?

So now I see that "newrole" command is enough, no need to use su or sudo.

I have used custom PS1 prompt line to indicate immediately when shell terminal gets broken:

PS1="\`if cat /proc/self/fdinfo/0 | egrep -q 'flags:.*4'; then echo TERMINAL BROKEN; else echo TERMINAL OK; fi ;\`\n"

So here is a log of my (staff_t member) user shell session:

TERMINAL OK
strace -F -o newrole.strace newrole -r sysadm_r
Password:
TERMINAL OK
/etc/init.d/sshd status
Authenticating j.
Password:
 * status: started
TERMINAL BROKEN
cat /proc/self/fdinfo/0
pos:    0
flags:  0104002
mnt_id: 18
TERMINAL BROKEN
logout
TERMINAL OK

This reproduces in both tmux and bare text-mode console.
"strace" part is optional, it behaves the same way without it.
run_init, rc-service command give exactly same result.

Just as I expected, I found quite some O_NONBLOCK touching in strace log (attaching), and also in newrole.c in selinux git repo. However, the sources seem to be mostly not modified in many years, while for me this issue started just several months ago.

What could help is localization of what exactly from openrc init files triggers this. I guess it may be pretty printing, but I don't know how I could run just that in isolation.
Comment 4 Andriy Utkin (RETIRED) gentoo-dev 2017-06-09 23:45:15 UTC
Created attachment 475802 [details]
newrole.strace.gz
Comment 5 Jason Zaman gentoo-dev 2017-06-12 01:28:49 UTC
(In reply to Andrey Utkin from comment #3)
> I may try =sys-apps/policycoreutils-9999 if that may help. Which version do
> you run Jason?

2.7_rc1 was just released a couple days ago. I will add it to the repo shortly. Give that one a shot when it shows up. I am on the -9999 packages so that could explain it.

Are you on a super new kernel or something? I'm still on 4.9 i wonder if anything changed in ttys in later ones.
Comment 6 Andriy Utkin (RETIRED) gentoo-dev 2017-06-14 23:40:07 UTC
(In reply to Jason Zaman from comment #5)
> (In reply to Andrey Utkin from comment #3)
> > I may try =sys-apps/policycoreutils-9999 if that may help. Which version do
> > you run Jason?
> 
> 2.7_rc1 was just released a couple days ago. I will add it to the repo
> shortly. Give that one a shot when it shows up. I am on the -9999 packages
> so that could explain it.

Still reproduces with policycoreutils-2.7_rc1. Is -9999 worth trying?

> 
> Are you on a super new kernel or something? I'm still on 4.9 i wonder if
> anything changed in ttys in later ones.

This issue reproduces on both of my workstations, they are on kernels 4.9.30 and 4.9.14 (that one is on policycoreutils-2.6-r1 still).
Comment 7 Andriy Utkin (RETIRED) gentoo-dev 2017-06-30 15:18:06 UTC
Still reproduces on policycoreutils-9999
Comment 8 dwfreed 2017-07-02 03:33:06 UTC
Created attachment 479260 [details, diff]
Patch to clear nonblock flag on stdin before exit

Please try the attached patch against policycoreutils.  It shouldn't matter which version you try it with, but I did create it against 9999.  If this fixes the issue, you can blame perfinion for breaking it.
Comment 9 Andriy Utkin (RETIRED) gentoo-dev 2017-07-07 01:27:17 UTC
(In reply to dwfreed from comment #8)
> Created attachment 479260 [details, diff] [details, diff]
> Patch to clear nonblock flag on stdin before exit
> 
> Please try the attached patch against policycoreutils.  It shouldn't matter
> which version you try it with, but I did create it against 9999.  If this
> fixes the issue, you can blame perfinion for breaking it.

Thanks for looking into this and for the patch.

Rebuilt sys-apps/policycoreutils-2.7_rc1 with the patch, it fixes the issue.
Comment 10 Jason Zaman gentoo-dev 2017-07-12 06:06:42 UTC
Stephen fixed this upstream now. it will be in the next release (probably final, i dont think there will be an rc5)

commit fb081eb64b36a9de5a43f3d69d9e628b6eb1afc7
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Tue Jul 11 01:03:01 2017

    open_init_pty: Do not make stdin and stdout non-blocking
    
    It is unclear why this was being done in the first place, and
    it has caused multiple bugs with run_init/open_init_pty usage.
    
    Fixes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
    Fixes: https://bugs.gentoo.org/show_bug.cgi?id=621062
    Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Comment 11 William Hubbs gentoo-dev 2017-10-12 23:59:15 UTC
What is the status of this bug? Can we close it?
Comment 12 Jason Zaman gentoo-dev 2017-10-29 14:24:05 UTC
selinux userspace 2.7 is stable now