So the issue here is I need to modify the environment of a user, say ironman from root. I tried the following:
su -l ironman -c 'source my_bash.sh'
The my_bash.sh just contains a script that modifies some environment stuff but the above doesn't seem to work. When I try to logon to ironman and check the environment, it remains unchanged.
Related
I have a lot of configuration for Kwin (the window manager) in another user's home folder (/home/B/.config and other folders).
Is there a way to run Kwin from my session, but make Kwin consider the other user's configuration and environment as well?
I can't copy the files over to my account because they're scattered around B's home folder, and I don't want to risk overwriting stuff.
I tried using sudo, but it doesn't run the command as if it was the B's session, and uses my own config files to run the program instead of those in /home/B/.
If the -H sudo parameter is not enough, maybe you also need something from shell resource files that -i would give you, so something like sudo -i -uusername command.
From sudo's man page:
-i, --login Run the shell specified by the target user's password
database entry as a login shell. This means that
login-specific resource files such as .profile or
.login will be read by the shell. If a command is
specified, it is passed to the shell for execution
via the shell's -c option. If no command is
specified, an interactive shell is executed. sudo
attempts to change to that user's home directory
before running the shell. The command is run with an
environment similar to the one a user would receive
at log in. The Command environment section in the
sudoers(5) manual documents how the -i option affects
the environment in which a command is run when the
sudoers policy is in use.
I am adding below command in sudoers file, but it is giving me syntax error not allowing "foo=bar" before command.
user ALL=(runas) SETENV:NOPASSWD:foo=bar /path/to/command /path/to/script
If I add using /bin/bash prefix this worked
user ALL=(runas) SETENV:NOPASSWD:/bin/bash -c "foo=bar /path/to/command /path/to/script"
but when I run sudo from user it asks me for a password.
Can someone please let me know How should this work?
Your command list must be a file in your filesystem indicated its full path. I´m not quite sure what your foo=bar "command" should even mean. If that is a variable being set, aren´t you lacking a semicolon (foo=bar;)? But anyways, sudo is not about setting variables either way, it´s about running commands. You should just get rid of foo=bar altogether and keep
user ALL=(runas) SETENV:NOPASSWD: /path/to/command /path/to/script
You wouldn´t use sudo to stop a user from setting a variable (if that is what you even meant in the first place).
from manpages:
A Cmnd_List is a list of one or more command names, directories, and
other aliases. A command name is a fully qualified file name which
may include shell-style wildcards (see the Wildcards section below).
Hello I would like to understand the differences w.r.t env that gets setup using sudo su - vs just a sudo su.
User already a part of sudoers
Not able use few kerberos commands when I use just sudo su.
A look in the manual page for the su command showed the following:
-, -l, --login
Start the shell as a login shell with an environment similar
to a real login:
o clears all the environment variables except TERM
o initializes the environment variables HOME, SHELL,
USER, LOGNAME, and PATH
o changes to the target user's home directory
o sets argv[0] of the shell to '-' in order to make
the shell a login shell
So, if you use sudo su - the above mentioned variables are erased and filled with information according to your new user (root or another).
Maybe some needed environmental variables are set for your root user?
Unfortunately, I haven't worked with kerberos yet.
Hope I helped you a bit.
After searching all over the internet, I came know where to alter the values of PATH variable in case of interactive/non-interactive - login/non-login shell combinations.
Found from another post
https://shreevatsa.wordpress.com/2008/03/30/zshbash-startup-files-loading-order-bashrc-zshrc-etc/
I have "/bin/sh" as default login shell and only /etc/profile file is being used to export all needed environment variables in my system. And in case of non-interactive login shell, /etc/profile is not being referred too, even though above link says it would. But still when I execute,
ssh -4 -q -o StrictHostKeyChecking=no root#xxxx "env"
Password:
SHELL=/bin/sh
...
**PATH=/usr/bin:/bin:/usr/sbin:/sbin**
...
I could see some default values for PATH variable. I would like to know where exactly these default values of PATH are being set.
You should not care at all where PATH is set. You should set PATH always in your shell startup file (.profile or .bashrc).
This way you do not rely on someone else's soon useless assumption what directories should be in your PATH. The only one who knows is YOU.
Start out with
PATH=$(getconf PATH)
and then add to your liking with
PATH=$PATH:$HOME/bin
PATH=$PATH:/usr/local/bin
PATH=$PATH:<...any other directory you need...>
PS: In your specific case, it looks like the PATH is inherited from the remote end's SSH daemon which eventually forks your shell. If a shell does not inherit a PATH from its parent, it will set a default value that you can query with env -i /bin/sh -c 'echo $PATH'.
It depends on your distribution. In Debian and its derivatives, the definition is found in /etc/environment and it is read into the current session by inclusion of pam_env.so in the appropriate /etc/pam.d/ files.
Can someone explain the difference between su -p (--preserve-environment) and su - when switching user at the command-line?
I'm familiar with "su -" but it's unclear to me how su -p differs, if at all.
The difference is that with su -p you can preserve all the personalization you did with your original user. For example, you preserve your alias, your bashrc, profile ...
In simple words:
- using "su" you get SuperUser's rights **and** environment
- using "su -p" you get only SuperUser's rights (the environment stays your own)
As you can see in the su manpage it says "do not reset environment variables".
Unix shells allow you to store values in variables. It even uses this itself (i.e. the PATH variable saves the location of executables). If you use -p you keep your environment variables, instead of getting the ones from the new user.
(However they might still be overwritten by whatever shell initation scripts that user has..)