User Environment..

[John E Hein at work]

Mamnoon. Ovace (BVSG) wrote at 15:41 +0100 on Jun 14:
 > I am trying to setup sudo on a Dec Unix system. Everything works well except
 > I cant figure out how to solve the below problem.
 > 
 > In addition to running a command as a different user, I need to be able to
 > load that users environment before the command can be run.
 > 
 > I need to use something analogous to "su - <user> -c <command>" , currently
 > when I run "sudo -u <user> <command>" the result is similar to running "su
 > <user> -c <command>"..
 > 
 > Can anyone help..


sudo is not itself a shell.  That is, it doesn't read .login,
 .cshrc, .profile, .bashrc, etc., files.

To do that you typically would use a shell, but you can certainly
 reinvent a shell-like program to try to read what the user wants for
 an environment from some files.

Here's a couple examples:

1)
assuming the user keeps his env in ~/.profile for bourne
 shell, here's one way:

sudo -u foo -H env ENV=${HOME}/.profile sh -c 'some_command args ...'


2)
if you don't know/care what their shell is:

sudo su - foo -c 'some_command args ...'

This assumes that Dec Unix understands 'su -' to simulate a full login
 for the user.  And it assumes that the shell that the user employs groks
 '-c' to run the named command (sh does, csh does, tcsh does, ksh does;
 but that doesn't mean that the user doesn't run some home grown shell
 that might not understand -c).


3)
do it yourself...

sudo -H -u foo read_in_users_env_and_exec_a_named_cmd

The 'read_in_users_env_and_exec_a_named_cmd' would have to assume that the
 user's env is in a certain file(s) and would have to make a guess as to
 the style of the env in that file(s) (csh style or bourne shell style,
 etc.).  Or you could have people keep their env in a shell-language
 independent ~/.env file that 'read_in_users_env_and_exec_a_named_cmd'
 can parse.

Without getting into any more detail, you can see that #3 is a pain,
 and that's probably one reason why sudo doesn't try to read users'
 env from some file in the user's home dir.  That's what shells are for.


I think #2 is really what you want.  It still uses
 "su - <user> -c <command>", but just has sudo as a front end.