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 coreutils-6.10-18.fc9.i386 How reproducible: 100%
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.
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 HOSTNAME=localhost.localdomain TERM=xterm SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=192.168.1.51 52603 22 SSH_TTY=/dev/pts/2 USER=nopriv LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:do=00;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.svgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.dz=00;31:*.gz=00;31:*.bz2=00;31:*.tbz2=00;31:*.bz=00;31:*.tz=00;31:*.deb=00;31:*.rpm=00;31:*.jar=00;31:*.rar=00;31:*.ace=00;31:*.zoo=00;31:*.cpio=00;31:*.7z=00;31:*.rz=00;31:*.jpg=00;35:*.jpeg=00;35:*.gif=00;35:*.bmp=00;35:*.pbm=00;35:*.pgm=00;35:*.ppm=00;35:*.tga=00;35:*.xbm=00;35:*.xpm=00;35:*.tif=00;35:*.tiff=00;35:*.png=00;35:*.mng=00;35:*.pcx=00;35:*.mov=00;35:*.mpg=00;35:*.mpeg=00;35:*.m2v=00;35:*.mkv=00;35:*.ogm=00;35:*.mp4=00;35:*.m4v=00;35:*.mp4v=00;35:*.vob=00;35:*.qt=00;35:*.nuv=00;35:*.wmv=00;35:*.asf=00;35:*.rm=00;35:*.rmvb=00;35:*.flc=00;35:*.avi=00;35:*.fli=00;35:*.gl=00;35:*.dl=00;35:*.xcf=00;35:*.xwd=00;35:*.yuv=00;35:*.svg=00;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36: MAIL=/var/spool/mail/nopriv PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/nopriv/bin INPUTRC=/etc/inputrc PWD=/home/nopriv LANG=en_US.UTF-8 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SHLVL=1 HOME=/home/nopriv SDL_AUDIODRIVER=esd LOGNAME=nopriv SSH_CONNECTION=192.168.1.51 52603 192.168.1.184 22 LESSOPEN=|/usr/bin/lesspipe.sh %s G_BROKEN_FILENAMES=1 _=/bin/env $ rpm -ql coreutils | grep /bin/su /bin/su /usr/bin/sum $ 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
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?
no AVC errors
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.
And additionally ls -Z /bin/su and lsattr /bin/su , please. TIA.
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
[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
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 targeted [root@delta alpha-usr-share-selinux]# diff -ur targeted/ /usr/share/selinux/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 . /etc/selinux/ receiving incremental file list delta-transmission enabled ./ config 501 100% 489.26kB/s 0:00:00 (xfer#1, to-check=123/125) [...] [root@delta ~] # diff -ur alpha-etc-selinux/ /etc/selinux/ > diff-ur-alpha-etc-selinux-delta-etc-selinux
Thanks for additional info. Adding D.Walsh to CC as possible source of troubles is in selinux(policies).
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.
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= --iso=sec 2008-04-09T04:23:49-0400 $ rpm -qa | grep -i selinux libselinux-2.0.61-1.fc9.i386 libselinux-python-2.0.61-1.fc9.i386 selinux-policy-targeted-3.3.1-31.fc9.noarch libselinux-devel-2.0.61-1.fc9.i386 selinux-policy-3.3.1-31.fc9.noarch
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 ~]#
Ok, changing component to firstboot.
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'.
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 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...
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.
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).
(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 true [beta@beta firstboot]$ if false; then echo true; else echo false; fi false [beta@beta firstboot]$ true && echo true || echo false true [beta@beta firstboot]$ false && echo true || echo false false [beta@beta firstboot]$ cat /etc/sysconfig/firstboot RUN_FIRSTBOOT=NO [beta@beta firstboot]$ if grep -qs 'RUN_FIRSTBOOT=NO' /etc/sysconfig/firstbootxx; then echo true; else echo false; fi false [beta@beta firstboot]$ if grep -qs 'RUN_FIRSTBOOT=NO' /etc/sysconfig/firstboot; then echo true; else echo false; fi true [beta@beta firstboot]$ if grep -qs 'RUN_FIRSTBOOT=NOxx' /etc/sysconfig/firstboot; then echo true; else echo false; fi false
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).
What does # semanage login -l show?
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.
Fresh installs are now okay, so moving from F9PR -> F9Blocker
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.
(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.
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?
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.
yes, it is fixed now. sorry for not being clearer