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.
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.
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.
In my Debian server, all users run sh, but root runs bash;
when i start a ssh connection, i log in with my personal account that does not have root privileges;
i've installed rvm and I want to use it as root because using it from my personal user, it fails installing everything since the user does not have permissions to write where is neeeded; so everytime i need to type
source /usr/local/rvm/bin/rvm
before being able to use rvm; to avoid typing source command everytime, in sh i know i can put the command in /etc/profile file; is there something similar for bash?
I've tried to add "echo aaa" to /etc/profile, to see what happen;
when i login as my personal user, i get the "aaa" output; but when i type su and login as root, nothing happens... I think that when i use "su" command and login as root, the /etc/profile is not read
The same happens after installing by rvm a ruby release: I setup the default ruby version (as root) and then the ruby command is available for my personal user (but if i do "su" again and try to type "ruby -v" as root, i get "command not found"
Another thing: after login with my personal user, the rvm command is available; after typing "su", no more; if I add the source command to /etc/profile, once login is done with personal user, i can see a screen output from rvm (some kind of doc); the same happens after using the source command as root
bash -- being an extension of sh -- also reads /etc/profile.
bash specific alternatives include ~/.bash_profile for login shells, and ~/.bashrc and for non-login shells.
/etc/bash.bashrc is the global config for bash, though /etc/profile is usually sourced by bash as well.
You may need to run the command with 'sudo' in order to actually run it as root. I believe the shell config scripts for any shell will run as the user that is launching the shell. If you prefer, you could also run the binary in an 'sh' shell as well:
sudo /bin/sh -c /usr/local/rvm/bin/rvm
Here's some more info, just in case: https://wiki.debian.org/sudo
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..)
I would like my root-requiring bash script to be run from IntelliJ/WebStorm, asking me for the root password when I run it. Having my root password hardcoded in the script is a bad idea of course.
IntelliJ/WebStorm actually has a $Prompt$ macro for reasons like this, which prompts you and uses your input as a value.
So I tried using $Prompt$ along with echo YOURPASSWORD | sudo -S yourcommand as described in use-sudo-with-password-as-parameter.
Then I pass passwd & script to run to a sudorun.sh script echo -e $1 | sudo -S $2 $3 $4 (since echo can't be be the 'program' line) which although works on the CLI, it fails to read echo-stdin on the IntelliJ console.
Ideally, I would like the solution to be configured solely from within IntelliJ and not require specific OS configuration changes outside of IntelliJ.
Perhaps there are other ways to deal with this, so lets improvise!
I, too, faced the same issue, but I work with sensitive data on my development machine and removing the password requirement for sudoers just isn't an option.
I was able to resolve this issue by launching the actual WebStorm application from the command line using the sudo command as follows:
sudo /Applications/WebStorm.app/Contents/MacOS/webide
Once WebStorm/PhpStorm are launched this way, you can run a script with root access without supplying root credentials.
Use the NOPASSWD feature of sudo. Add a rule like so to sudoers (via visudo or similar):
someuser ALL = NOPASSWD: /usr/bin/interesting_program
%somegroup ALL = NOPASSWD: /usr/bin/interesting_program
I find myself automating a lot of my workflow, and running into the same issue. I don't want to punch a hole in my sudoer permissions, and I don't want to run my IDE as root either. A good solution that I've found is gksudo, on Ubuntu and many other Linux variants you'll find it installed by default. What gksudo does is it allows you to prompt the user(yourself) to input your password with a graphic overlay, much like Ubuntu/KDE/etc. do when you need to be root to perform an operation such as an update.
This will then prompt you to provide your password to escalate privilege, then execute a given command/program as root.
In the Edit Tool Window simply:
Set the Program to /usr/bin/gksudo
gksudo may be located at a different path, try: whereis gksudo to find its path
Set Parameters to all commands you want to execute in quotes
Ex. "mongod --fork --config /etc/mongodb.conf; service elasticsearch start"
Make sure you have the quotes!
Set a working directory(if needed)