Now I have what I think is a problematic scenario as I am actually
running sh for what I can see, that is my login shell for root after
all, but I have the BASH_VERSION environment variable set from my
earlier login, passed along via the sudo mechanism? Correct me if I am
wrong.
Fortunately, you're wrong. The BASH_VERSION
and similar environment variables are set, but not exported, so they don't exist for child processes.
Compare the output of:
set | grep ^BASH
with
env | grep ^BASH
Both set
and env
display environment variables. set
is a shell built-in, and it sees the BASH_*
variables. env
is an external program, and you'll notice that it doesn't see the BASH_*
variables at all.
If you did want to export those variables to child processes, you could do it manually, and then it would show up in env
:
$ export BASH_VERSION
$ env | grep ^BASH
BASH_VERSION=4.2.36(1)-release
But unless you've manually exported them like this, you can be fairly sure that the presence of BASH_VERSION
means that you are actually running bash. See also the output of export -p
to figure out which variables are going to be exported in this way.
You should configure sudo security policy to allow user xyz exec something as user abc. Read 'man sudoers' and use visudo command to configure /etc/sudoers.
For example let's allow user xyz exec /usr/bin/whoami as user abc without password. Add this string into /etc/sudoers (with visudo, don't edit /etc/sudoers directly):
xyz ALL = (abc) NOPASSWD: /usr/bin/whoami
And now test it:
xyz@host:~$ sudo -u abc /usr/bin/whoami
abc
Best Answer
-s /bin/bash
overrides nologin and allows to interpret value of-c
option-c "/usr/bin/echo -n foo"
allows to avoid using dash-starting first argument