I'm not completely sure if I should ask here, over at the Unix forums or somewhere completely different but, here we go.
I'm using Packer to create a set of images (running Debian 8) for AWS and GCE, and during this process I want to install HAProxy and set up a config file for it. The image building and package installation goes smooth, but I'm having problems with file permissions when I'm trying to either create the config file or overwrite the existing one.
My Packer Shell Provisioner runs a set of scripts as the user admin (as far as I know I can't SSH into this setup with root), where as the one I'm having trouble with looks like this:
#!/bin/bash
# Install HAProxy
sudo apt-get update
sudo apt-get install -y haproxy
# Create backup of default config file
sudo mv /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
# Write content over to new config file
OLDIFS=$IFS
IFS=''
sudo cat << EOF > /etc/haproxy/haproxy.cfg
# Content line 1
# Content line 2
# (...)
EOF
IFS=$OLDIFS
The log output gives me this error: /tmp/script_6508.sh: line 17: /etc/haproxy/haproxy.cfg: Permission denied
I've also thought of having a premade config file moved over to the newly created image, but I'm not sure how to do that. And that wouldn't work without writing permissions either, right?
So, does anyone know how I can set up my Shell script to fix this? Or if there is another viable solution?
The problem with the script is the line
sudo cat << EOF > /etc/haproxy/haproxy.cfg
The redirection to /etc/haproxy/haproxy.cfg happens before sudo is called, and thus requires that the file can be created and written to by whatever user is running the script.
Your idea of changing the permissions and ownership of that file solves this issue by making the file writable by the user running the script, but really, you seem to be executing every single line of the script as root in any case, so why not just drop all the sudos altogether and run the whole thing as root?
$ sudo myscript.sh # executed by the 'admin' user
EDIT: Since this script isn't run on the target machine manually, there are two solutions:
Go with the chmod solution.
Write the config file to a temporary file and move it with sudo.
The second solution involves changing the line
sudo cat << EOF > /etc/haproxy/haproxy.cfg
to
cat <<EOF >/tmp/haproxy.cfg.tmp
and then after the EOF further down
sudo cp /tmp/haproxy.cfg.tmp /etc/haproxy/haproxy.cfg
rm -f /tmp/haproxy.cfg.tmp
This is arguably "cleaner" than messing around with file permissions.
As Kusalananda pointed out, the problem is that output redirection happens in the shell which calls sudo.
In such situations I generally use this simple trick:
TMPFILE=`tempfile`
cat << EOF > $TMPFILE
# Content line 1
# Content line 2
# (...)
EOF
sudo cp $TMPFILE /etc/haproxy/haproxy.cfg
rm $TMPFILE
I create a temp file and put content there (no need for sudo for that step). And then with sudo, copy the temp file to the final destination. Finally: delete the temp file. (I use the copy to make the file ownership to belong to the root; the move would keep the user/group of the calling user. Alternatively, one can use the chmod/chown to fix the permissions.)
The solution to this was quite simple, and 123's comment gave me the right answer: chown
By changing this
sudo mv /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
to this
sudo chown admin /etc/haproxy/haproxy.cfg
sudo chmod 644 /etc/haproxy/haproxy.cfg
sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
I now have both the permissions and ownership I need for my setup to work.
EDIT
Other users have provided better and more viable solutions, as well as answered some issues around my script.
I am creating a script meant to be run as superuser that reads a file and runs a number of scripts on behalf of all users. The important bit is this:
sudo -u $user -H source /home/$user/list_of_commands
However, whether I encose the command with quotesor not, this fails with:
sudo: source /home/user/list_of_commands: command not found
I have even tried with the . bash builtin:
sudo: . /home/user/list_of_commands: command not found
Of course running source outside a sudo environment works. I thought there might be a PATH problem, and I tried to bypass it by providing the full path to source. However, I cannot find the executable: which source returns which: no source in (/usr/local/sbin:usr/local/bin:usr/bin). So I'm stuck.
How do I make a script source a file as a user?
source is a builtin not a command, use it with bash -c:
sudo -u $user -H bash -c "source /home/$user/list_of_commands"
For some reason I need, as user, to run without sudo a script script.sh which needs root privileges to work.
I saw as the only solution to put sudo INSIDE script.sh. Let's take an example :
script.sh :
#!/bin/sh
sudo apt-get update
Of course, if I execute this script, I get a prompt asking me for a password. Then I added to my sudoers file (at the end to override everything else) :
user ALL=(ALL:ALL) NOPASSWD:/path/to/script.sh
By the way, I also tried the line :
user ALL=(ALL) NOPASSWD:/path/to/script.sh
(I think I didn't fully understand the difference)
But this doesn't solve my problem if I don't use sudo to execute this script :
# ./script.sh
[sudo] password for user:
# sudo ./script.sh
Starts updating...
Well, so I say to myself "Ok, that means that if I have a file refered in sudoers as I did, it will work without prompt only if I call him with sudo, what is not what I want".
So, ok, I create another script script2.sh as following :
script2.sh
#!/bin/sh
sudo /path/to/script.sh
In fact it works. But I am not truly satisfied of this solution, particularly by the fact that I have to use 2 scripts for every command.
This post is then for helping people having this problem and searching for the same solution (I didn't find a good post on it), and perhaps have better solutions coming from you guys.
Feel free to share your ideas !
EDIT 1 :
I want to insist on the fact that this "apt-get update" was just an example FAR from whhat my script actually is. My script has a lot of commands (with some cd to root-access-only config files), and the solution can't be "Well, just do it directly with apt-get".
The principle of an example is to help the understanding, not to be excuse to simplify the answer of the general problem.
From my blog: IDMRockstar.com:
The kicker is that sometimes, I need to run commands as root. Here's the quick and dirty way I accomplish that without divulging the passwords:
#! /bin/bash
read -s -p "Enter Password for sudo: " sudoPW
echo $sudoPW | sudo -S yum update
This way the user is prompted for the password (and hidden from terminal) and then passed into commands as needed, so I'm not running the entire script as root =)
If you have a better, way, I'd love to hear it! I'm not a shell scripting expert by any means.
Cheers!
.: Adam
If you want to run sudo /usr/bin/apt-get update without a password, you need to have the sudoers entry:
user ALL=(ALL:ALL) NOPASSWD:/usr/bin/apt-get update
For the larger issue of the script as a whole, there are two possible approaches:
Approach 1
For each command in the script that needs sudo, create a line in sudoers specifically for that command. In this case, the script can be called normally:
./script1.sh
Approach 2
Place a line in sudoers for the script as a whole. When this is done, the individual commands do not need sudo. However, sudo must be used to start the script as in:
sudo ./script.sh
If your password isn't something you want to be very secure about, (maybe some testing server in the company etc.) you can elevate to sudo in the script via echo like:
echo YourPasswordHere | sudo -S Command
The prompt still prints the "enter password" text to output though. So don't expect it to be neat.
See this Askubuntu post
As you noted, the file that must appear in the sudoers configuration is the one that is launched by sudo, and not the one that runs sudo.
That being said, what we often do, is having something like
user ALL=(ALL:ALL) NOPASSWD:/path/to/script.sh
in the sudo configuration, where script.sh has all the commands that the script has to do.
Then we define either a Bash function or an alias so that script.sh is actually
sudo /path/to/script.sh
The only issue is if some commands must not be run as root, you need to insert some su - user -c "command" commands in the script.
In new /etc/sudoers.d/apt-get file, put single line:
user ALL=(ALL:ALL) NOPASSWD:/usr/bin/apt-get update
Fully qualified path to executable is required here.
Then use following in your script:
sudo apt-get update
Here, fully specified name is not required. Sudo uses PATH environment variable for executable resolution.
While changing and checking sudoers configuration, be sure to keep another root session open for error recovery.
I suggest you look at the sudo environment variables - specifically you can use (and check for) $SUDO_USER. Call your script with sudo (1 entry in sudoers), then do user stuff as SUDO_USER and root stuff as root.
As mentioned by Basilevs you need to add your user to the sudoers file in order to avoid that sudo commands in the script get stuck awaiting the password.
On Ubuntu 16, there is a simpler way: just add the user to the sudo group, like this:
sudo usermod -aG sudo *username*
From then on, it should work like a charm.
Note:
This works only on the condition that the following line is in file /etc/sudoers:
%sudo ALL=NOPASSWD: ALL
(such line gives passwordless sudo privileges at group level, in this case to the sudo group)
(if this line is not present and you want to add it, make sure you use visudo)
Simply, in order to execute commands as root you must use su (even sudo uses su)
As long as you execute sudo ./script2.sh successfully just instead :
sudo su
"#" //commands as root here
"#" exit
//commands as use here
you can make it a shell function with the name sudo, but no other better way i think,however it's the case with scripts inti,rc android ..etc
must be tidy ;)
however this requires you to put NOPASSWD: su wich is totaly secure indeed
any way here just lacks POISX permissions principle which is filtering so dont enable something to all users or vice versa
simply, call sudo as much as you want with no additional thing then:
chown root script.sh
chmod 0755 script.sh
chgrp sudo script.sh
"make root owner of .sh"
"make it read only and exec for others"
"and put it in sudo group"
of course under sudo
that's it
I need to run these two commands :
ulimit -s 1024
echo 120000 > /proc/sys/kernel/threads-max
The first one can be run just in user mode (not using sudo or su) and the second can only be run in su mode. I want to write a bash script that let me run these two commands. The first one is OK. For the second one, I need to su (change user to root), run the command, and then exit. Actually, I want to run the second command in su mode using a bash script. Any idea?
If your user has permission to use "sudo tee", then one solution is:
echo 120000 | sudo tee /proc/sys/kernel/threads-max
As a security measure, you cannot run scripts as a superuser without prepending sudo. If you want it to be passwordless, you need to run visudo and allow your (or the executing user) to run this command as a superuser without password confirmation.
The other way is to use the setuid bit on compiled code. Compile a simple program which will execute the echo 120000 > /proc/..., then change it to be owned by root: chown 0:0 executable_name, and chmod u+s executable_name to set the setuid bit on it. This will cause execution of this program to be ran with permissions of its owner, which is root.
This is the same way which allows passwd to modify a file which requires super-user privileges without actually being a super-user or sudoer.
Please [1] consider this command: sudo incrontab ~/incron-config where ~/incron-config contains:
/home/zetah/doc IN_CREATE,IN_MOVED_TO /home/zetah/scripts/do_something.sh $#/$#
and do_something.sh consists of [2]:
#! /bin/bash
python /home/zetah/scripts/py_something.py "$1"
Python script accesses some online services and produces 3 new files. They are owned by root.
Why is that and how can I change this behavior. I want to be the owner of those product files
Thanks
[1] Posted on Ask Ubuntu previous - thought to try my chances here, will interlink in any result
[2] Seems lame to wrap Python script in Bash script, but I couldn't do it otherwise
created files are owned by root probably because you run incrontab as root and then python inherit from it through bash
You can run incrontab from your own user, simply add your username in /etc/incron.allow (to allow you to use incron) and then recreate the incron table with your account with "incrontab -e" (don't forget to remove the entry from root)
Second option (if you can't modify incron.allow) is to call python with your username.
In your bash script, modify :
python /home/zetah/scripts/py_something.py "$1"
in
su <username> -c"python /home/zetah/scripts/py_something.py '$1'"
Hope it's help
ericc