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_aliases
all 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.