So, I have an entry that looks like this in my sudoers file:
user1 ALL=(user2) NOPASSWD: /scripts/dir/
This allows user1 to run all executables under /scripts/dir/ as user2 without entering their password using a command like sudo -u user2 /scripts/dir/script. However, I ran into issues where the executables expect to be run with user2's environment ($PATH, $DISPLAY, etc). user1 can accomplish that by running something like sudo -iu user2 /scripts/dir/script which simulates a login shell, but with the above sudoers entry, this doesn't work and they're prompted to enter their password. Is there a sudoers entry that will alow user1 to run this command or at least be able to source user2's .bashrc, .cshrc, etc. when running commands?
I have found the SETENV option, but that allows user1 to preserve their existing environment, not take on user2's environment. I could do source /home/user2/.bashrc followed by sudo -Eu user2 /scripts/dir/script; this would give user1 user2's environment which will be preserved by the -E option, but this assumes that user1 has read access to the .bashrc file and that the script does not try to execute any commands that user1 does not have permission to run.
The sudoers man page states the following about the -i option to sudo:
As a special case, if sudo's -i option (initial login) is specified, sudoers will initialize the environment regardless of the value of env_reset. The DISPLAY, PATH and TERM variables remain unchanged; HOME, MAIL, SHELL, USER, and LOGNAME are set based on the target user. On AIX (and Linux systems without PAM), the contents of /etc/environment are also included. On BSD systems, if the use_loginclass flag is enabled, the path and setenv variables in /etc/login.conf are also applied. All other environment variables are removed.
which seems to indicate that it's possible to provide the -i option with some sudoers configuration, perhaps by giving user1 permission to run ALL commands or specifically allowing the -i option in sudoers, but I'm hoping there is a more fine-grained way of achieving this. Also, it seems to indicate that PATH and DISPLAY will come from user1's environment which is not what I want.
Of course, I could give user1 more permissions than necessary in order to accomplish this, but that presents security risks.
