su: Permission denied (credentials correct)

Question

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.

Answer 1

I suspect there is something wrong with one of the scripts which get called when you spawn a login shell, as opposed to those called by a non-login shell.

Have a look at the INVOCATION section of man bash

Mine reads:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

...

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc.

For the "minor error" bash: /home/admin/.bashrc: Permission denied.

This is because the HOME environment variable of the admin user is coming access and the myuser user does not have permission to access the $~/.bashrc, which is what bash does when spawning a new shell.

Answer 2

I did a diff -rw on /etc/pam.d/ between this system and a similar system that does not have this su -l problem. I found /etc/pam.d/su-l had this line uncommented:

auth           required        pam_wheel.so use_uid

It is normally commented so as to not impose this requirement. None of the other similar files in /etc/pam.d/ had this line uncommented, hence the inconsistent behavior of different variants of the command.

I solved the issue by commenting that line:

# auth           required        pam_wheel.so use_uid