The error always looks something like this, depending on which shell is configured in /etc/passwd.
su: failed to execute /usr/sbin/jk_chrootsh: Permission denied
OR
su: failed to execute /bin/bash: Permission denied # for a more typical shell
Upon examining both the permissions and file access control lists for /bin/bash, located in /usr/bin/bash, they seem to allow the user backups to read and execute both shells.
┌─[✓]─[u@h]─[~]
└──$ stat --format %a /usr/sbin/jk_chrootsh # Get chmod code
777
┌─[✓]─[u@h]─[~]
└──$ stat --format %a /usr/bin/bash
755
┌─[✓]─[u@h]─[~]
└──$ getfacl /usr/sbin/jk_chrootsh
getfacl: Removing leading '/' from absolute path names
# file: usr/sbin/jk_chrootsh
# owner: root
# group: root
user::rwx
group::rwx
other::rwx
┌─[✓]─[u@h]─[~]
└──$ getfacl /usr/bin/bash
getfacl: Removing leading '/' from absolute path names
# file: usr/bin/bash
# owner: root
# group: root
user::rwx
user:backups:rwx #effective:r-x
group::r-x
mask::r-x
other::r-x
The chmod code of 777 for /bin/bash will clearly allow rwx access to anyone, and the file access control list shows even a specific override for my user to have rwx access.
The chmod code of 755 should also give enough access for jk_chrootsh, with rx access being granted to everyone. Additionally, the facl shows nothing that would restrict the execution ability of anyone to /usr/sbin/jk_chrootsh.
I was concerned that maybe the sbin directory, usually being only for use with the root user, would be blocking read access, but it also allows read and execute access to anyone. I guess it just is not on the default PATH variable for non-root users.
This is the backups user’s line in /etc/passwd if needed, too:
backups:x:1002:1002:,,,:/opt/backups/./.:/usr/sbin/jk_chrootsh
Does anyone have any possible leads for solving this problem?
Edit:
As per harrymc‘s request, /opt/backups/ has the permission code 777, yet is owned by root:root, as sshd requires root to own chroot directories.
