/bin/ksh as default user shell not working
doncuppjrl opened this issue · 7 comments
If I have a group with a sudoers line like
%un-privileged_group ALL=(ALL) NOPASSWD: /usr/bin/strace
, and the default shell of a user(test_user) is /bin/bash,
I can run sudo -u test_user /usr/bin/strace without issue.
Now, if I change the default shell for test_user to /bin/ksh, I get prompted for a password..unless I add /bin/ksh to the sudoers like
%un-privileged_group ALL=(ALL) NOPASSWD: /bin/ksh, /usr/bin/strace
Why does sudo not treat the shells the same way? Is this a bug or desired behavior?
You shouldn't need to have the shell listed in the sudoers rule unless you are running sudo -i. If you are not using the -i option then the target user's shell is not used.
Ah yes well, that is indeed one of the commands we are running. For testing, and because we want the .ksh_profile to run
I just think it odd, that I can switch to a user interactively, without declaring the shell in sudoers as long as the shell is bash.
You probably have another rule that allows bash to be run. When you use "sudo -i command" what happens is the command gets expanded to "shell -c command" before sudoers is consulted. So previously it would have been "/bin/bash -c /usr/bin/strace" but now that the shell has changed sudo will the the sudoers file for "/bin/ksh -c /usr/bin/strace".
That's what it feels like for sure, but as I understand it, these kinds of directives do not compile or augment, but rather replace any previous matching rule. Anyways, this is the sudoers.
# Refuse to run if unable to disable echo on the tty.
#
Defaults !visiblepw
#
# Preserving HOME has security implications since many programs
# use it when searching for configuration files. Note that HOME
# is already set when the the env_reset option is enabled, so
# this option is only effective for configurations where either
# env_reset is disabled or HOME is present in the env_keep list.
#
Defaults always_set_home
Defaults match_group_by_gid
# Prior to version 1.8.15, groups listed in sudoers that were not
# found in the system group database were passed to the group
# plugin, if any. Starting with 1.8.15, only groups of the form
# %:group are resolved via the group plugin by default.
# We enable always_query_group_plugin to restore old behavior.
# Disable this option for new behavior.
Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults env_keep += "SSH_CONNECTION TERM"
#
# Adding HOME to env_keep may enable a user to run unrestricted
# commands via sudo.
#
# Defaults env_keep += "HOME"
#Defaults secure_path = /u01/app/oracle/product/19.3.0.0/dbhome_1/bin:/u01/app/oracle/product/19.3.0.0/dbhome_1/OPatch:/u01/app/grid/product/19.3.0.0/gridhome_1/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/oracle:/usr/ucb:/bin:/usr/bin:.:/usr/local/bin:/opt/perf/bin:/var/opt/oracle:/usr/sbin:/opt/perf/bin:/usr/contrib/bin:/usr/contrib/bin/X11:/usr/ccs/bin:/home/oracle/dbascripts/dbajobs:/home/oracle/dbascripts/dbajobs/utilities:/home/oracle:/usr/ucb:/bin:/usr/bin:.:/usr/local/bin:/opt/perf/bin:/var/opt/oracle:/usr/sbin:/opt/perf/bin:/usr/contrib/bin:/usr/contrib/bin/X11:/usr/ccs/bin:/home/oracle/dbascripts/dbajobs:/home/oracle/dbascripts/dbajobs/utilities:/home/oracle:/usr/ucb:/bin:/usr/bin:.:/usr/local/bin:/opt/perf/bin:/var/opt/oracle:/usr/sbin:/opt/perf/bin:/usr/contrib/bin:/usr/contrib/bin/X11:/usr/ccs/bin:/home/oracle/dbascripts/dbajobs:/home/oracle/dbascripts/dbajobs/utilities:/home/oracle/dbascripts/dbajobs/backup
Defaults secure_path = /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/u01/app/grid/product/19.3.0.0/gridhome_1/bin
## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
## user MACHINE=COMMANDSin
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root ALL=(ALL) NOPASSWD: ALL
## Allows members of the 'sys' group to run networking, software,
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS
## Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL
%un-privileged_group ALL=(ALL) NOPASSWD: /usr/bin/strace
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
## Allows members of the users group to mount and unmount the
## cdrom as root
# %users ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom
## Allows members of the users group to shutdown this system
# %users localhost=/sbin/shutdown -h now
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
##includedir /etc/sudoers.d
I don't see anything obvious there (unless you were running sudo as root before) but if you had previously run sudo -u test_user /usr/bin/strace when the target user's shell was bash but sudo -i -u test_user /usr/bin/strace with the shell set to ksh that would explain it.
Running sudo as root? Why would anybody do this?