I need to run a shell script as another user while logged in as root. Something along the lines of
su <user> ./scriptname -d
where the -d bit is the switch to be passed to scriptname.
However, when I attempt to execute the command as shown above su complains that -d is not a valid option and presents me with a list of valid options. How do I get it to understand that the -d is meant for consumption by the script not itself?
su <user> -c './scriptname -d'
Related
I install Pip for a user (not system wide) and I would like to check that pip is installed for that user in my script that I run with sudo: sudo ./script.sh
I know to check for a command with command -v pip3 and that works when I enter it in the shell as the user.
But how can I check it in my script?
command -v pip3 exit code is 1 because I am root (because of sudo).
su -c "command -v pip3" "$SUDO_USER" has exit code 1.
sudo -u "$SUDO_USER" command -v pip3 says "command: command not found"
The simplest is
sudo -u "$SUDO_USER" -i command -v pip3
The -i option causes sudo to pass the supplied command line to the user's configured shell using its -c option, instead of trying to execute the command directly. That's necessary because command is a shell built-in; it doesn't exist as a stand-alone executable. (The -i options runs a "login" shell. There is also the -s option which runs a non-login shell. See below.)
If you want to specify a shell explicitly you could do so instead:
sudo -u "$SUDO_USER" /bin/sh -lc "command -v pip3"
Again, a login shell is forced, here by using the -l option.
As a safety feature, sudo normally resets the $PATH to a "safe" value before executing the shell (or the single command). That value will not have any of the modifications made in the /etc/profile and ~/.profile startup scripts, and without those modifications -- which add one or more user-specific directories to the path -- the shell will not find software such as pip3 which has been installed for individual users.
use following command by replacing $USER with the specific user name.
sudo -H -u $USER bash -c 'command -v pip3'
similarly, you can run any command as another user
syntax : sudo -H -u $USER bash -c 'INSERT_COMMAND_HERE'
I have a requirement where I am trying to write a shell script which is calling curl command internally. I have the password, username and url stored as variables in the script. However, since I want to avoid using user:password format of curl command in the script, I am just using curl --user command. My intention is to pass the password through stdin. So, I am trying something like this -
#!/bin/bash
user="abcuser"
pass="trialrun"
url="https://xyz.abc.com"
curl --user $user $url 2>&1 <<EOF
$pass
EOF
But this is not working. I know there are variations to this question being asked, but I didn't quite get the exact answer, hence posting this question.
You can use:
curl -u abcuser:trialrun https://xyz.abc.comp
In your script:
curl -u ${user}:${pass} ${url}
To read from stdin:
curl https://xyz.abc.com -K- <<< "-u user:password"
When using -K, --config specify - to make curl read the file from stdin
That should work for HTTP Basic Auth, from the curl man:
-u, --user <user:password>
Specify the user name and password to use for server authentication.
To expand on #nbari's answer, if you have a tool "get-password" that can produce a password on stdout, you can safely use this invocation:
user="abcuser"
url="https://xyz.abc.com"
get-password $user | sed -e "s/^/-u $user:/" | curl -K- $url
The password will be written to a pipe. We use sed to massage the password into the expected format. The password will therefore never be visible in ps or in the history.
I have set the PATH environment and then run psql on command prompt and then whatever command I write nothing happens, it doesn't throw any error message too.
even very basic commands as;
psql -l
pg_dump -U {user-name} {source_db} -f {dumpfilename.sql}
Do you have any idea?
You have to finish each command with a semicolon (;). Until you do so, psql thinks you're still writing the same (multi-line) command.
Also, psql -l and pg_dump -U {user-name} {source_db} -f {dumpfilename.sql} are not psql commands. These should be ran from your shell (without the semicolons), not from the psql terminal.
I'm trying to write a bash script that runs a mysqldump command that uses the -p flag. This flag prompts the user for a password, which works as expected when run in the shell directly, but does not appear when run in a script.
#!/usr/bin/env
ssh user#domain.com 'mysqldump -u mysqluser -p --databases foo | bzip2' > ~/temp/foo-dump.sql.bz2
Now I could embed the password in the script or pass it as an arguments, but I really want the script to prompt the user for the password so the password doesn't show up in my scripts repo or in my bash history.
Anyone have any idea on how to accomplish this?
This should do the trick:
read -p "mysql password: " PASS && ssh user#domain.com 'mysqldump -u mysqluser -p'$PASS' --databases foo | bzip2' > foo-dump.sql.bz2 ; PASS=""
In this case, you will first enter the mysql password, and then be prompted for the ssh password. Note that the mysql password will not be hidden, i.e., someone can read it over your shoulder. If you want to avoid that, use the flag -s
read -s -p "mysql password: " PASS && ...
Note also that there mustn't be any space between the "p" (in -p for password) and the quotation mark for the password variable.
Also, your shebang is not specifying which interpreter to use, which might be a problem. I'd suggest you use #!/bin/bash or #!/usr/bin/env bash.
I had a bash script which called sudo -i -u user /bin/bla/whatever. That worked fine until the last update to CentOS 5.8.
That's the corresponding entry in the sudoers file:
Runas_Alias TEST = user1, user2
Defaults:test always_set_home
test ALL=(TEST) NOPASSWD: /bin/bash -c /bin/bla/whatever, /bin/bla/whatever
If I used sudo -i it seems it called the command
"/bin/bash -c /bin/bla/whatever"
(regarding the secure log). Now, since the update, it seems to call
"/bin/bash -c \/bin\/bla\/whatever"
and therefore is not allowed to. I tried to change the line in the sudoers file to
test ALL=(TEST) NOPASSWD: /bin/bash -c /bin/bla/whatever, /bin/bla/whatever, /bin/bash -c \/bin\/bla\/whatever
but thats not allowed syntax, so I tried:
test ALL=(TEST) NOPASSWD: /bin/bash -c /bin/bla/whatever, /bin/bla/whatever, /bin/bash -c \\/bin\\/bla\\/whatever
That's valid syntax but doesn't work either.
If I use sudo -H -u user /bin/bla/whatever it works fine. Even if I allow /bin/bash in the sudoers file, but that would allow anything.....
Any ideas?
Erik
Just checked the sudo man page on my fedora 16 system and it says:
-i [command]
The -i (simulate initial login) option runs the shell specified by the password database entry of the target user 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.
So it does not appear to be necessary to specify bash -c in your sudoers command definition.
If you call the command as sudo -i /bin/bla/whatever you should need nothing more than the following in your sudoers file:
test ALL=(TEST) NOPASSWD: /bin/bla/whatever
I can reproduce the problem on my fedora 16 system, no changes to the sudoers file I tried had any effect. I cannot find any other configuration required to make this work. All I can say is to use '-H -u ...'.
Were you running sudo -i -u user /bin/bla/whatever with arguments? From man sudoers:
A simple file name allows the user to run the command with any arguments he/she wishes. However, you may also specify command line arguments (including wildcards). Alternately, you can specify "" to indicate that the command may only be run without command line arguments.
So once you add in the /bin/bash -c you are now specifying arguments and they must match exactly.
Here's an example sudoers line:
test ALL=(ALL) NOPASSWD: /bin/bash -c /bin/true, /bin/bash -c /bin/true *, /bin/true *
With that I can do:
sudo /bin/true
sudo /bin/true foo
sudo -u /bin/true
sudo -u /bin/true foo
But not sudo true because that becomes bash -c true which does not match bash -c /bin/true.