This question already has an answer here:
Single vs double quotes confusion in Bash [duplicate]
(1 answer)
Closed 10 months ago.
I'm installing Poetry in a dockerfile, but I want to do it under a different user (to play nicely with VSCode). I don't understand the behavior of the su command though.
When I run su vscode -c "echo $HOME" I get /root. However, when I run su vscode, and subsequently run echo $HOME, I get /home/vscode`.
Even stranger, when I run su vscode -c "echo $HOME && curl -sSL https://install.python-poetry.org | python3", I get /root as output of the first command, but poetry is installed to /home/vscode/.local/bin. I'm at a loss here... can someone shine some light on this?
"echo $HOME" is evaluated by your current shell before su is executed. So su will only be passed as argument "echo /root" (already-evaluated). If you want the variable to be evaluated by the shell spawned by su, you need to escape it: 'echo $HOME'
See 2.2 Quoting in the POSIX specification
Related
This question already has answers here:
How to escape the single quote character in an ssh / remote bash command?
(5 answers)
Closed 9 months ago.
Im using ssh with a system that has a lot of security settings. The bash command I want to run is:
ssh –t user#address su –c ‘echo “user ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers.d/permissions’
This command does not work since su does not recognize the stuff after it as a command. EOF is disabled by default for ssh and EOSU is disabled by default on all computers in the network. Sudo is also disabled for the user on the host computer. Is there a clean way to do this while calling su as little as possible?
Note: I already did keygen stuff so the ssh login is passwordless, root login through ssh is disabled by default.
When you pass a command to ssh, it requires quoting both from the local shell and the remote shell.
A fix for your case would be to move the first single quote slightly, to prevent the local shell from messing with the command at all. In the internal quoting, we use nested double quotes where the inner ones are backslashed.
ssh –t user#address 'su –c "echo \"user ALL=(ALL) NOPASSWD:ALL\"" >> /etc/sudoers.d/permissions’
I am running Fedora 20 on my desktop. When I saw the advisory about the vulnerability in bash, I checked my system out and turns out, it was vulnerable. Today, I updated my system and a new version of bash was installed. I was expecting to restart bash for the changes to take effect. But to my surprise, the update process somehow fixed running copy of bash.
How?
Log:
shows 2 invocations of the same command. Between the two, upgraded the system from a different xterm window.
bash$ env x='() { :;}; echo vulnerable' bash -c "echo This is a test"
vulnerable
This is a test
bash$ env x='() { :;}; echo vulnerable' bash -c "echo This is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
If you split the command into two it's clearer:
env x='() { :;}; echo vulnerable'
bash -c "echo This is a test"
You're running a new instance of bash when checking for the bug, so it's using the updated code. You should make sure to restart all your shells to ensure that you're safe.
I'm trying to set a fake date via bash script
I'm using the following commands:
#!/bin/bash
echo 'myPass' | sudo -s 'date -s "1 NOV 2011 09:00:00"'
But I'm getting command error.
What is the right way to do it ?
sudo does not read the password from standard input by default, but from the terminal itself, so you cannot pipe your password into sudo this way. You need to use the -S option to read from standard input.
echo "myPass" | sudo -S date -s "1 NOV 2011 09:00:00"
(note that you don't need to use the -s (lowercase) option; sudo can run date directly without starting an intervening shell).
Exposing your password like this, however, is a security risk. It would be better to configure sudo to allow you (or anyone who is intended to run this script) to run
this particular date command without a password.
For sudo, the first parameter without a dash is the command to execute, the following parameters are the arguments to give to that command. If you wrap the command and its arguments together in quotes (e.g. "echo foo"), then sudo tries to execute the command "echo foo" instead of the command "echo" with parameter "foo". Hence, you need to omit the outermost quotes:
sudo date -s "1 NOV 2011 09:00:00"
I'm having trouble with the following bash script:
#!/bin/bash
myPassword="foobar"
su - postgres <<-'EOF'
echo $myPassword # nil
EOF
echo $myPassword # foobar
How can I access or pipe the contents of $myPassword from within the postgres user session?
Tried it with and without export with not luck.
You're using 'EOF' for the heredoc marker. So no substitution happens. Remove the quotes around that if you want variable substitution inside the block. See Heredocs And Herestrings.
You could also keep what you have, but use the -p (or -m or --preserve-environment) option of su which might work better for you.
(I'm sure there's no need to remind you that keeping passwords in scripts is unsafe. And a process's environment can be inspected with sufficient privileges, so it's not a great place for passwords either.)
you probably need to escape \$mypassword so that it doesn't get resolved in the original script before calling su
also, you can pass -c to su in order to pass something from the environment to the spawned shell:
user1:~$ X=foo su -c "bash -c \"whoami && echo \$X\"" user2
Password:
user2
foo
This su command should work:
myPassword="foobar"
su postgress -c "echo $myPassword"
I've got a shell script which I am trying to run as a specific user. My command looks like this:
su - jetty sh ./runProgram.sh
When I attempt to run this command through the console I get an error saying:
/bin/sh: /bin/sh: cannot execute binary file
I also tried:
su - jetty sh runProgram.sh
And I still get the same error..
It DOES work if I do this:
sh runProgram.sh
But this shell script is meant to be run by a specific user. Any advice on how to get this working??
Try
su - jetty -c sh runProgram.sh
According to su's documentation (info coreutils 'su invocation'), it will by default execute a shell, and the arguments to su are passed as arguments to the shell.
The implication is simply this: su is doing in essence:
/bin/sh *arguments_to_su*
but it does it as another user (the "effective user id")... that's all... So
su - jetty sh ./runprogram.sh
is akin to
(become the user jetty via login or su)
/bin/sh sh ./runprogram.sh
...and the shell will report an error, because the first /bin/sh, called by su, is trying to run the program sh as a shell script, with ./runprogram.sh as its argument. But sh itself is not a shell script, it is a binary (whose job it is is to run shell scripts).
if you were to simply do this:
su - jetty ./runprogram.sh
Then the su command will call /bin/sh with the program ./runprogram.sh as its argument, and jetty as the effective user id, and all should be well. ...SHOULD be well, because since you are doing an su - you are making the shell a login shell and changing to the user's home directory. If runprogram.sh is not in the home directory, you will get an error.
This is why, also, you cannot run for example run a cp command by simply:
su - jetty cp file1 file2
...because, again, after su changes effective user id to jetty it will try this:
/bin/sh cp file1 file2
...and cp is not a shell script. But the -c option works in this case; because you are telling su that you want to run /bin/sh with the -c option to the shell:
su - jetty -c "cp file1 file2"
does the job. Note that you must quote the command, because the entire string is passed to the shell and (I believe) any following arguments are ignored.
Finally, the previous poster's answer doesn't work for me on Linux, it requires the entire command string to be quoted.