I found a lot of solutions for parts of that problem, but not for the combination. So here is the plan:
#!/bin/bash
echo "current home »$HOME«"
sudo -u git -H /bin/bash << END_OF_SCRIPT
GitToolsRepo=$HOME/git-tools
echo "using git tools at »$GitToolsRepo«"
END_OF_SCRIPT
echo finally
running this script with sudo as auser, unfortunately this always puts
current home »/home/auser«
using git tools at »«
finally
Assuming user git's home is set to /var/lib/git I expect something like
current home »/home/auser«
using git tools at »/var/lib/git«
finally
User git has no login shell set (security)
I also tried
su -s /bin/bash git - << END_OF_SCRIPT
with identical result.
So how can I in a script run a set of script lines as a different user and having its environment set as I would have when executing su -s /bin/bash git - on command line?
Even more difficult with {}
#!/bin/bash
echo "current home »$HOME«"
su -s /bin/bash git - << END_OF_SCRIPT
GitToolsRepo=${HOME}/git-tools
echo "using git tools at »${GitToolsRepo}«"
END_OF_SCRIPT
echo finally
You need to escape $ in script input block.
Hence correct script will be
#!/bin/bash
echo "current home »$HOME«"
sudo -u git -H /bin/bash << END_OF_SCRIPT
GitToolsRepo=\$HOME/git-tools
echo "using git tools at »\$GitToolsRepo«"
END_OF_SCRIPT
echo finally
For all readers coming here for the same problem: I figured it is much better to put the part for the other user in a separate script and have either option in one line:
sudo -u user bash -c script.sh
sudo -u user script.sh
su user -c "bash script"
this it is debuggable and no ugly escaping
Related
From Jenkins I try to send bash scripts to a host, where those bash scripts should be run. All those scripts have to be run in the same directory on the host. I do not want to provide this directory to each script, so I would like to cd into this directory and then run the script.
On the host the default shell is /bin/sh. In my .bashrc I set some variables, so I instruct bash to load my .bashrc with BASH_ENV. I run scripts with ssh user#host BASH_ENV='~/.bashrc' 'bash -s' < myscript.sh $appdir. This actually works, now when I remove $appdir from myscript.sh and ssh user#host BASH_ENV='~/.bashrc' "cd $appdir ; bash -s" < myscript.sh, variables from .bashrc are no longer available.
Following is a simple reproduction of this problem, only user, host and /path/to/git have been changed after the commands have been executed. git is added to $PATH in .bashrc, otherwise it is not available.
This works:
$ ssh user#host BASH_ENV='~/.bashrc' 'bash -c "type git" ; pwd'
git is /path/to/git
/home/user
This does not work:
$ ssh user#host BASH_ENV='~/.bashrc' 'cd ; bash -c "type git" ; pwd'
bash: line 0: type: git: not found
/home/user
There are different parts of SSH and Bash that I do not understand. I would be grateful for any information that would help me understand this problem.
I have below script named as sample.sh
#!/bin/bash
echo "inside script file"
echo whoami
echo cftping -v
echo "Ping completed"
I am running it as other user with the help of below command.
sudo -H -u xfbcft bash -c 'bash /data/_temp/sample.sh'
I am getting below output:
xfbcft
/data/_temp/sample.sh: line 4: cftping: command not found
Ping completed
When I sudo to xfbcft directly then I can run 'cftping -v' command but not via above shell script. Could anyone guide me here?
I'm creating a bash script to set up an Ubuntu 16.04 lts OS to download, install and other stuff without introduce each command separately and I have to write in the /etc/profile file to add a PATH environment variable. When my code get into that line it appears the Permission Denied message, this is what I have:
sudo echo "export PATH=$PATH:/usr/local/go/bin" >> /etc/profile
bash: /etc/profile: Permission denied
Do you know how could I solve this?
Shell i/o redirection happens before the shell executes your command...in other words, when you write:
sudo somecommand >> /etc/profile
The >> /etc/profile part is performed as the current user, not as root. That's why you're getting the "permission denied" message. There are various ways of solving this. You can run:
sudo sh -c "echo export PATH=$PATH:/usr/local/go/bin >> /etc/profile"
Or you can take advantage of the append (-a) flag to the tee command:
echo "export PATH=$PATH:/usr/local/go/bin" | sudo tee -a /etc/profile
sudo sh -c "echo MY_GLOBAL_ENV_TO_MY_CURRENT_DIR=$(pwd)" >> /etc/environment"
I want to default to bash (or zsh) in my ssh sessions, so I tried adding exec bash -l to a shell profile that I know is being accessed: .cshrc.
This appeared to work, but my trial-and-error ways are coming back to haunt me. The command scp me#host:file . only works when I remove the exec bash -l line.
Is this the right way to login to a bash shell, or should I do something else? Perhaps a local solution in my actual ssh me#host call.
If the specific errors are relevant I'll paste them in an edit, but I suspect the problem is I'm doing it wrong...
Use chsh command to change your default login shell.
Print the list of shells available:
chsh -l
Change default shell:
chsh -s /bin/bash <username>
Get the default login shell of the current user:
getent passwd <username> | cut -d: -f7
I'm writing a bash shell script that has to be run with admin permissions (sudo).
I'm running the following commands
sudo -u $SUDO_USER touch /home/$SUDO_USER/.kde/share/config/kcmfonts > /dev/null
sudo -u $SUDO_USER echo "[General]\ndontChangeAASettings=true\nforceFontDPI=96" >> /home/$SUDO_USER/.kde/share/config/kcmfonts
The first command succeeds and creates the file. However the second command keeps erroring with the following:
cannot create /home/username/.kde/share/config/kcmfonts: Permission denied
I can't understand why this keeps erroring on permissions. I'm running the command as the user who invoked sudo so I should have access to write to this file. The kcmfonts file is created successfully.
Can someone help me out?
Consider doing this:
echo "some text" | sudo -u $SUDO_USER tee -a /home/$SUDO_USER/filename
The tee command can assist you with directing the output to the file. tee's -a option is for append (like >>) without it you'll clobber the file (like >).
You don't need to execute the left side with elevated privs (although it is just echo, this is a good thing to form as a habit), you only need the elevated privs for writing to the file. So with this command you're only elevating permissions for tee.
sudo -u $SUDO_USER echo "some text" >> /home/$SUDO_USER/filename
sudo executes the command echo "some text" as `$SUDO_USER".
But the redirection is done under your account, not under the $SUDO_USER account. Redirection is handled by the shell process, which is yours and is not under the control of sudo.
Try this:
sudo -u $SUDO_USER sh -c 'echo "some text" >> /home/$SUDO_USER/filename'
That way, the sh process will be executed by $SUDO_USER, and that's the process that will handle the redirection (and will write to the output file).
Depending on the complexity of the command, you may need to play some games with escaping quotation marks and other special characters. If that's too complex (which it may well be), you can create a script:
$ cat foo.sh
#!/bin/sh
echo "some text" >> /home/$SUDO_USER/filename
$ sudo -u $SUDO_USER ./foo.sh
Now it's the ./foo.sh command (which executes as /bin/sh ./foo.sh) that will run under the $SUDO_USER account, and it should have permission to write to the output file.