There are a lot of questions with similar titles. I believe I have checked them all before asking this question.
My error is su: Permission denied and the user switch is not completed. Here are the details.
ssh admin@remote-machine su --login myuser Password: su: Permission denied (the password is correct) RESULT: failed to switch users
However, the following does work, even though it reports a minor error:
su --preserve-environment myuser Password: bash: /home/admin/.bashrc: Permission denied RESULT: succeeds to switch users
Also, plain su myuser without any parameters works. These variants also work:
su -P myuser su -s /bin/sh myuser Even though I have a work-around, I want to understand this issue. Also, my preferred form of the command, su - user is the one that does not work. This issue only affects one remote device, even though I have several that appear to be configured identically. They all run Arch Linux.
I'm not using SELinux. From reading the other questions, I checked a few things.
user@remote-machine [/home/myuser] # ls total 13904 drwx--x---+ 1 myuser myuser 3210 Feb 18 16:00 . -rw-r--r-- 1 myuser myuser 396 Aug 13 2018 .bashrc # getfacl /home/myuser/ getfacl: Removing leading '/' from absolute path names # file: home/myuser/ # owner: myuser # group: myuser user::rwx user:sddm:--x group::--- mask::--x other::--- # ls /home/admin/.bashrc -rw-r--r-- 1 admin admin 624 Apr 17 17:08 /home/admin/.bashrc less /etc/passwd myuser:x:1000:1000:myuser myuser:/home/myuser:/bin/bash In /etc/pam.d/su the following line is commented out (which is the default):
# auth required pam_wheel.so use_uid EDIT: added info as requested.
First, I did a diff -rw on /etc/profile.d/ between this system and a similar system that does not have this su -l problem. There are no differences. Both contain only the standard Arch Linux scripts in /etc/profile.d/.
There is one change in /etc/profile itself from the stock Arch Linux file. But this change is present in both the correctly working system and the one with the su -l problem. The only change in /etc/profile is umask 006.
/etc/bash.bashrc
# If not running interactively, don't do anything [[ $- != *i* ]] && return [[ $DISPLAY ]] && shopt -s checkwinsize HISTFILESIZE= HISTSIZE= HISTCONTROL=ignorespace case ${TERM} in xterm*|rxvt*|Eterm|aterm|kterm|gnome*) PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"' ;; screen*) PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033_%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"' ;; esac [ -r /usr/share/bash-completion/bash_completion ] && . /usr/share/bash-completion/bash_completion The files shown below are in the user account I issued the su command from. But this issue affects any user changing to any other user. I don't see any of the user accounts with modified files (for ~/.bash_profile, ~/.bash_login, and ~/.profile). There is no .bash_login in any account or in /etc.
Both of the next files are bare-bones.
~/.bash_profile
[[ -f ~/.bashrc ]] && . ~/.bashrc ~/.bashrc
# If not running interactively, don't do anything [[ $- != *i* ]] && return In one account, ~/.bashrc has:
if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi - the aliases in
.bash_aliasesall look OK. The issue also affects users with no aliases defined. /etc/security/limits.conf- no lines (other than comments both working & non-working devices have the same empty file)/etc/securetty- stock Arch Linux (no changes to file & both working & non-working devices have the same lines)/etc/passwd- 644 perms/etc/- 755 perms
SOLUTION: /etc/pam.d/su-l (but not any of the other files in /etc/pam.d/) required pam_wheel.so use_uid. See accepted answer for more. Now that this is resolved, this question contains a comprehensive checklist for this issue. Hopefully it will be a good reference for others.
