Bug 441511

Summary: su - does not work for non-privileged users on initial login
Product: [Fedora] Fedora Reporter: John Poelstra <poelstra>
Component: libuserAssignee: Miloslav Trma─Ź <mitr>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: archimerged, dwalsh, ovasik, twaugh, wwoods
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-18 12:34:56 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235706    
Description Flags
run on delta: diff -ur alpha-etc-selinux /etc/selinux
Fix syntax error and update comments in /etc/rc.d/init.d/firstboot
incorrect correction to patch to /etc/rc.d/init.d/firstboot
Patch /etc/rc.d/init.d/firstboot none

Description John Poelstra 2008-04-08 11:02:21 EDT
Description of problem:
Logging in as a regular user and then executing 'su -' results in error of "su
command not found"

If you log in as root and 'su - nopriv-user' it works fine as does subsequently
executing 'su -' as this non-privileged user.

Version-Release number of selected component (if applicable):
rawhide 20080408

How reproducible:
Comment 1 Ondrej Vasik 2008-04-08 15:40:35 EDT
Tried on my machine (non-rawhide) with rawhide coreutils and it works fine, so
it seems to be something rawhide specific.

When you got this command not found message, could you please store 
1)PATH envvar (maybe not set/or set incorrectly?)
2)rpm -ql coreutils | grep /bin/su

Which runlevel it was? Any or just specific one(text or X11)? Was possible to
run runuser instead of su in that case? 

TIA for those additional informations, will try tomorrow on rawhide machine.
Comment 2 John Poelstra 2008-04-08 16:04:35 EDT
All I did was install today's rawhide and login as a nonpriv user I had just
created. no difference between desktop or remote access.  runnlevel 5

$ env
SSH_CLIENT= 52603 22
LESSOPEN=|/usr/bin/lesspipe.sh %s

$ rpm -ql coreutils | grep /bin/su

$ file /bin/su
/bin/su: ERROR: cannot open `/bin/su' (Permission denied)

$ runuser - 
runuser: cannot set groups: Operation not permitted

[root@localhost ~]# file /bin/su
/bin/su: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
[root@localhost ~]# ls -la /bin/su
-rwsr-xr-x 1 root root 35356 2008-04-07 14:25 /bin/su

[root@localhost ~]# runlevel
N 5

Comment 3 Ondrej Vasik 2008-04-08 16:16:31 EDT
Thanks for those additional infos... and what about SELinux? Was the result same
with Permissive (I guess default is Enforcing)? Was AVC denial about access to
su in selinux log? 
Comment 4 John Poelstra 2008-04-08 16:34:28 EDT
no AVC errors
Comment 5 Ondrej Vasik 2008-04-09 04:02:50 EDT
Just tried with Fedora rawhide not the latest snapshot, but with latest
coreutils package(i don't have any machine with the latest snapshot at the
moment)) and su - for non-privileged user works there for both SELinux
modes(Enforcing and Permissive). Could you please make strace log of the su -
failure? Just to see what file caused the permission denied error. TIA.
Comment 6 Ondrej Vasik 2008-04-09 04:20:09 EDT
And additionally ls -Z /bin/su and lsattr /bin/su , please. TIA.
Comment 7 archimerged Ark submedes 2008-04-09 10:43:44 EDT
Only an install gets the problem.  yum update does not.  
Also problem goes away if you turn enforcing off.

Installed Rawhide-2008-04-08 (timestamp = 1207643440.58):
[root@delta ~]# ls -Z /bin/su
-rwsr-xr-x  root root system_u:object_r:su_exec_t:s0   /bin/su
[root@delta ~]# lsattr /bin/su
-------------- /bin/su
[delta@delta ~]$ strace /bin/su
strace: /bin/su: command not found
[delta@delta ~]$ strace ls /bin/su
stat64("/bin/su", 0x86ffcf8)            = -1 EACCES (Permission denied)
[root@delta ~]# echo 0 > /selinux/enforce 
[delta@delta ~]$ cat /selinux/enforce 
0[delta@delta ~]$ ls -Z /bin/su
-rwsr-xr-x  root root system_u:object_r:su_exec_t:s0   /bin/su

Updated from F9beta to Rawhide-2008-04-08 (timestamp = 1207643440.58)
(but with miscellaneous manual changes...)
enforcing targeted
[alpha@alpha ~]$ ls -Z /bin/su
-rwsr-xr-x  root root system_u:object_r:su_exec_t:s0   /bin/su
[root@alpha ~]# lsattr /bin/su
-------------- /bin/su
[root@alpha ~]# ls -Z /bin/su
-rwsr-xr-x  root root system_u:object_r:su_exec_t:s0   /bin/su
Comment 8 archimerged Ark submedes 2008-04-09 11:08:42 EDT
[root@delta ~]# SELINUXPKGS=$(rpm -qa | grep selinux | sed 's/-[0-9].*//')
[root@delta ~]# echo $SELINUXPKGS
libselinux-python libselinux selinux-policy selinux-policy-targeted libselinux-devel
[root@delta ~]# rpm --verify $SELINUXPKGS
[root@delta ~]# ssh alpha rpm --verify $SELINUXPKGS
Comment 9 archimerged Ark submedes 2008-04-09 11:18:28 EDT
Created attachment 301829 [details]
run on delta: diff -ur alpha-etc-selinux /etc/selinux

delta had Rawhide-2008-04-08 installed; alpha did yum update.

[root@delta ~]# rsync --times -rvv --progress alpha:/usr/share/selinux/ .
[root@delta alpha-usr-share-selinux]# ls
[root@delta alpha-usr-share-selinux]# diff -ur targeted/
[root@delta alpha-usr-share-selinux]# cd ..
[root@delta ~]# mkdir alpha-etc-selinux
[root@delta ~]# cd alpha-etc-selinux/
[root@delta alpha-etc-selinux]# rsync --times -rvv --progress
alpha:/etc/selinux/ .
opening connection using: ssh alpha rsync --server --sender -vvtre.iL .
receiving incremental file list
delta-transmission enabled
	 501 100%  489.26kB/s	 0:00:00 (xfer#1, to-check=123/125)
[root@delta ~] # diff -ur alpha-etc-selinux/ /etc/selinux/ >
Comment 10 Ondrej Vasik 2008-04-09 12:43:40 EDT
Thanks for additional info. Adding D.Walsh to CC as possible source of troubles
is in selinux(policies).
Comment 11 Daniel Walsh 2008-04-09 13:28:59 EDT
The default SELinux user should be unconfined_u. This is the only SELinux user
that will be allowed to execute su.

semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              SystemLow-SystemHigh     
dwalsh                    staff_u                   s0                       
guest                     guest_u                   s0                       
mwalsh                    user_u                    s0                       
root                      unconfined_u              SystemLow-SystemHigh     
system_u                  system_u                  SystemLow-SystemHigh    

__default__ is the context for all users who are not listed.

If you have staff_u, user_u , or any other context this user will not be able to
execute setuid programs in general.

If you ended up with a __default__ pointing to a user other then unconfined_u by
default, this is a problem.

Comment 12 archimerged Ark submedes 2008-04-09 15:51:28 EDT
New install of Rawhide-2008-04-09 still has this problem
$ wget -qO - http://epsilon/Rawhide-2008-04-09/os/.treeinfo | grep time
timestamp = 1207729429.27
$ date --date=@1207729429.27 --iso=sec
$ rpm -qa | grep -i selinux
Comment 13 archimerged Ark submedes 2008-04-09 16:22:00 EDT
Created attachment 301893 [details]
Fix syntax error and update comments in /etc/rc.d/init.d/firstboot

Change component of this bug to firstboot.  The firstboot init script needs
fixing too: patch attached.

(hostname is localhost b/c I'm planning to test fix of a bug once I can run
system-config-network and change the hostname.)

This tree has syntax error in /etc/init.d/firstboot, and it fails first time
and leaves system with no CTL-ALT-F1 support and network not up, so you have to
press hardware reset button.

Second boot specified option S, fixed the syntax error, exit, continue loading,
went through the druid, and logged in.

The user created by firstboot is user_u, not unconfined_u.

[delta@localhost ~]$ secon 
user: user_u
role: user_r
type: user_t
sensitivity: s0
clearance: s0
mls-range: s0
[delta@localhost ~]$ su -
bash: su: command not found
[delta@localhost ~]$ ssh root@delta
root@delta's password: 
[root@localhost ~]# semanage login -l

Login Name		  SELinux User		    MLS/MCS Range	     

__default__		  unconfined_u		    s0			     
root			  root			    s0-s0:c0.c1023	     
system_u		  system_u		    s0-s0:c0.c1023	     
[root@localhost ~]# ls -Z /bin/su
-rwsr-xr-x  root root system_u:object_r:su_exec_t:s0   /bin/su
[root@localhost ~]#
Comment 14 Ondrej Vasik 2008-04-09 17:04:46 EDT
Ok, changing component to firstboot.
Comment 15 archimerged Ark submedes 2008-04-09 17:38:50 EDT
Created attachment 301901 [details]
incorrect correction to patch to /etc/rc.d/init.d/firstboot

Oops...  On testing, it didn't work.  Need 'if ! grep', not 'if grep'.
Comment 16 archimerged Ark submedes 2008-04-09 18:09:14 EDT
Sorry for the noise.  The problem was I didn't have execute privilege on the
script.  Then I checked things using grep -qs ... && echo true || echo false
instead of if grep -qs ... then echo true; else echo false; fi
which is not the same thing.

So the original patch is the correct one.
Comment 17 archimerged Ark submedes 2008-04-09 18:25:15 EDT
Comment on attachment 301893 [details]
Fix syntax error and update comments in /etc/rc.d/init.d/firstboot

This one is correct.  but I had some trouble running with rhgb quiet.  Running
without those boot options, and firstboot finally ran.	About to see if the
title bug also occurs then.  Also a clean install is in progress on alpha...
Comment 18 archimerged Ark submedes 2008-04-09 19:25:03 EDT
Created attachment 301907 [details]
Patch /etc/rc.d/init.d/firstboot

Fix syntax error and update comments in /etc/rc.d/init.d/firstboot.  Correct
the description in both chkconfig and INIT INFO sections.
Comment 19 archimerged Ark submedes 2008-04-09 19:32:33 EDT
And I have now confirmed that the new user created by firstboot is given u_user
instead of u_unconstrained, even if firstboot runs correctly on the first boot
(instead of failing with a syntax error).
Comment 20 archimerged Ark submedes 2008-04-09 20:03:22 EDT
(In reply to comment #16)
> Then I checked things using grep -qs ... && echo true || echo false
> instead of if grep -qs ... then echo true; else echo false; fi
> which is not the same thing.

Just pretend I didn't say that...

grep -qs returns 0 (true) if the file exists and the string is present.
It returns 1 (false) if the string is absent.
It returns 2 (false) if the file is absent.

[beta@beta firstboot]$ if true; then echo true; else echo false; fi
[beta@beta firstboot]$ if false; then echo true; else echo false; fi
[beta@beta firstboot]$ true && echo true || echo false
[beta@beta firstboot]$ false && echo true || echo false
[beta@beta firstboot]$ cat /etc/sysconfig/firstboot 
[beta@beta firstboot]$ if grep -qs 'RUN_FIRSTBOOT=NO'
/etc/sysconfig/firstbootxx; then echo true; else echo false; fi
[beta@beta firstboot]$ if grep -qs 'RUN_FIRSTBOOT=NO' /etc/sysconfig/firstboot;
then echo true; else echo false; fi
[beta@beta firstboot]$ if grep -qs 'RUN_FIRSTBOOT=NOxx'
/etc/sysconfig/firstboot; then echo true; else echo false; fi

Comment 21 Chris Lumens 2008-04-10 04:30:42 EDT
All firstboot is doing here is passing through to libuser to do the user
creation, so I would think this would be a problem in that library (unless
there's something I need to be calling to make sure to set the context correctly).
Comment 22 Daniel Walsh 2008-04-10 09:07:39 EDT
What does 
# semanage login -l  show?

Comment 23 Daniel Walsh 2008-04-10 11:38:48 EDT
The problem is that selinux-policy package blew up during the install

Prefix required error in install.log

This is preventing the unconfined_u selinux user from being added.

# semanage user -a -R "unconfined_r system_r" -P user -r s0-s0:c0.c1023 unconfined_u

Will add the record and your users should login with the correct SELinux user.

We are testing an updated selinux policy package with a fix.
Comment 24 Jeremy Katz 2008-04-11 10:19:53 EDT
Fresh installs are now okay, so moving from F9PR -> F9Blocker
Comment 25 John Poelstra 2008-04-11 13:55:29 EDT
Except that it takes a full 20 seconds from the time you enter your password and
hit return until you actually get a root prompt

Let me know if this should be a separate bug or a continuation of this issue.
Comment 26 Jesse Keating 2008-04-11 14:04:36 EDT
(In reply to comment #25)
> Except that it takes a full 20 seconds from the time you enter your password and
> hit return until you actually get a root prompt
> Let me know if this should be a separate bug or a continuation of this issue.

That sounds like a different bug, one that I can't reproduce here.  Please open
a new ticket on it.
Comment 27 Jeremy Katz 2008-04-17 02:31:24 EDT
The 20 seconds was due to permissions on /var/run/gdm (bug 442061).  

And I just did an upgrade from F8 and am able to run su perfectly fine -- are
you still having problems John?
Comment 28 Will Woods 2008-04-18 12:25:17 EDT
I've never managed to trigger this failure in any of my testing.

John seems to indicate that it's fixed in comment #25 - I think this is safe to close.
Comment 29 John Poelstra 2008-04-18 12:34:56 EDT
yes, it is fixed now. sorry for not being clearer