I have a minor complex command using a pipe
python3 wlan.py -p taken | awk '{$10 = sprintf( "%.1f", $10 / 60); print $4 $6 $8 $10 ",min"}' | awk '{gsub(/,/," ");print}' >> /tmp/missed.log
and I get a permission error if this command is executed from a program but not from the command line (sudo). So, obviously there is an issue with the rights of the program. I have set the rights of python and awk to 777 to no avail. But the main question is: What are the rights of the >> command and how can I change them?
the error message is "writing missed.log - permission denied".
File access in a Unix-like environment is tied to who you are, not what programs you run.* When you run sudo python3 ..., you are changing who you are to a more privileged user for the duration of the python3 command. Once Python stops running, you are back to your normal self. Imagine that sudo is Clark Kent taking off his glasses and putting on his cape. Once the badguys have been defeated, Superman goes back to an ordinary Joe.
Your error message indicates your normal user account does not have the necessary permissions to access / and /tmp, and to write /tmp/missed.log. The permissions on wlan.py and /usr/bin/python3 aren't the issue here. I can think of four options (best to worst):
Put the output file somewhere other than in /tmp. You should always be able to write your home directory, so you should be able to run without sudo, with > ~/missed.log instead of > /tmp/missed.log.
When you run your pipeline "from a program," as you said, just include the sudo as if you were running it from the command line. That way you get consistent results.
Add yourself to the group owning /tmp. Do stat -c '%G' /tmp. That will tell you which group owns /tmp. Then, if that group is not root, do usermod -a -G <that group name> <your username>.
Change the permissions on /tmp. This is the bludgeon: possible, but not recommended. sudo rm -f /tmp/missed.log and sudo chmod o+rwx /tmp should make it work, but may open other vulnerabilities you don't want.
* Ignoring setuid, which doesn't seem to be the case here.
Related
I am running a bash script and these commands in the script will not work without sudo in front of them. The script.sh is located in a folder such as /jobs/script.sh
Example of commands I am trying to run in the script.sh -
mv /var/app/myapp /var/app/myapp.old
rm file.tar.gz
tar -xzf /home/ubuntu/file.tar.gz -C /var/app/
All the above work if I add sudo in front of them.
I am trying to figure out what permissions are required for them to work without adding sudo in the script.
I have tried giving the script.sh rwx permissions and changing owner to root.
I'm learning permissions in linux, so I'm new to this. Basically what permission should the script.sh have so that I dont have to use sudo in the bash file? Any insight would greatly help.
When you run sudo <some command>, then <some command> is run by the root user (Super user do). The reason you might need to run any command using sudo is because the permissions on the files that command reads/writes/executes are such that only the "Super user" (root) has that permission.
When executing the command mv fileA fileB, the executing user would need:
Write permission to fileB if fileB already existed
Write permission to the directory containing fileB
From what you said it’s most likely you want read and write permissions you can achieve this with chmod
Chmod +[permission] filename
(+ is used to add permission you can also use - instead to remove it)
Where permissions can be:
r —> read
w—> write
x —>excecute
... and more
FOR EXAMPLE: it seems you write permissions for the first file so :
chmod +w /var/app/myapp
Will fix problem
I've created a simple bash script that grabs some data and then outputs it to a log file. When I run the script without sudo it fails to write to the logs and says they are write-protected. It then ask me if it should unwrite-protect them, but this fails (permission denied).
If I run the script as sudo it appears to work without issue. How can I set these log file to be available to the script?
cd /home/pi/scripts/powermonitor/
python /home/pi/powermonitor/plugpower.py > plug.log
echo -e "$(sed '1d' /home/pi/scripts/powermonitor/plug.log)\n" > plug.log
sed 's/^.\{139\}//' plug.log > plug1.log
rm plug.log
grep -o -E '[0-9]+' plug1.log > plug.log
rm plug1.log
sed -n '1p' plug.log > plug1.log
rm plug.log
perl -pe '
I was being dumb. I just needed to set the write permissions on the log files.
The ability to write a file depends on the file permissions that have been assigned to that file or, if the file does not exist but you want to create a new file, then the permissions on the directory in which you want to write the file. If you use sudo, then you are temporarily becoming the root user, and the root user can read/write/execute any file at all without restriction.
If you run your script first using sudo and the script ends up creating a file, that file is probably going to be owned by the root user and will not be writable by your typical user. If you run your script without using sudo, then it's going to run under the username you used to connect to the machine and that user will need to have permission to write the log files.
You can change the ownership and permissions of directories and files by using the chown, chmod, chgrp commands. If you want to always run your script as sudo, then you don't have much to worry about. If you want to run these commands without sudo, that means you're running them as some other user and you will need to grant write permission to that user, whoever it is, in order to write the files/folders where the log files get written.
For instance, if I wanted to run the script as user sneakyimp and wanted the files written to /home/sneakyimp/logs/ then I'd need to make sure that directory was writable by sneakyimp:
sudo chown -R sneakyimp:sneakyimp /home/sneakyimp/logs
This command changes ownership of that directory and its contents to the user sneakyimp. You might also need to run some chmod commands to make sure they are writable by owner.
I am trying to set up a cron on several AWS EC2 machines and would like to run a command on all of them at once, with the following shell script:
#!/bin/sh
cd /etc/cron.daily
touch ecs.sh
echo '#!/bin/sh' > /etc/cron.daily/ecs.sh
echo 'sudo yum update -y ecs-init' >> /etc/cron.daily/ecs.sh
echo 'sudo yum update -y' >> /etc/cron.daily/ecs.sh
sudo chmod 755 /etc/cron.daily/ecs.sh
cd ~
(crontab -u root -l; echo '0 0 * * * /etc/cron.daily/ecs.sh') | crontab -u root -
sudo yum update -y
The part that does not work is: chmod 755 /etc/cron.daily/ecs.sh
I am not sure, what am I missing.
If you can (have sufficient rights to) create a file, you do not need to sudo to change its permissions to 0755. Which would also likely prompt you to input your password and run non-interactively could be the reason why the action did not take place.
On the other hand, if the user running this did not have the necessary (write) permission, preceding lines creating the file would not happen either.
You also do not need to touch a file, because that > redirection will create it (always a new one).
You also should not cd somewhere and and continue performing actions without checking directory was changed as expected. But since on all action but the unnecessary touch you use absolute path names, you can just as well leave out both cd lines.
If you clean-up the script and it still does not perform expected action, it might be useful (assuming non-interactive execution) to save its output (redirect both standard > (or 1>) and error (2>) output to a file) and examine it for errors.
I have a bash script that partially needs to be running with default user rights, but there are some parts that involve using sudo (like copying stuff into system folders) I could just run the script with sudo ./script.sh, but that messes up all file access rights, if it involves creating or modifying files in the script.
So, how can I run script using sudo for some commands? Is it possible to ask for sudo password in the beginning (when the script just starts) but still run some lines of the script as a current user?
You could add this to the top of your script:
while ! echo "$PW" | sudo -S -v > /dev/null 2>&1; do
read -s -p "password: " PW
echo
done
That ensures the sudo credentials are cached for 5 minutes. Then you could run the commands that need sudo, and just those, with sudo in front.
Edit: Incorporating mklement0's suggestion from the comments, you can shorten this to:
sudo -v || exit
The original version, which I adapted from a Python snippet I have, might be useful if you want more control over the prompt or the retry logic/limit, but this shorter one is probably what works well for most cases.
Each line of your script is a command line. So, for the lines you want, you can simply put sudo in front of those lines of your script. For example:
#!/bin/sh
ls *.h
sudo cp *.h /usr/include/
echo "done" >>log
Obviously I'm just making stuff up. But, this shows that you can use sudo selectively as part of your script.
Just like using sudo interactively, you will be prompted for your user password if you haven't done so recently.
I am trying to get a start up script for OrientDB (a database) on Ubuntu to work.
This is currently the line that causes problems:
ORIENTDB_DIR="/usr/local/orientdb"
ORIENTDB_USER="www-user"
sudo -u $ORIENTDB_USER sh -c "cd \"$ORIENTDB_DIR/bin\"; /usr/bin/nohup server.sh 1>../log/orientdb.log 2>../log/orientdb.err &"
If I start the script, it results in this:
sh: 1: cannot create ../log/orientdb.log: Permission denied
Here's the setup:
www-user is in the sudoers file
server.sh and any the shell script posted above have execute privileges for root.
If I change the script to this:
sudo -u $ORIENTDB_USER sh -c "cd \"$ORIENTDB_DIR/bin\"; /usr/bin/nohup pwd 1>/home/www-user/test.log &", test.log shows /usr/local/orientdb/bin/ as the working directory.
/usr/local/orientdb/log exists but is an empty folder.
Given the above and the fact that I am using sudo to elevate the user, why is permission still denied?
You may have been misunderstanding sudo a bit — sudo does not necessarily elevate a user's rights; in fact, it may reduce the rights they have. When you pass sudo the -u flag, it will change to that user. If that user has more rights — root, for example (the default if -u is not passed) — then you'll get more rights. If the user has less rights — nobody, for example — you'll have less rights. You said that the log directory has these permissions:
drwxrwxr-x 2 root root 4096 Dec 11 10:13 /usr/local/orientdb/log
Yet, you're changing to the www-user user. The www-user user, unless it is part of the root group (unlikely), will not be able to write to that directory: it is only writable by the owner and group, and www-user is clearly not the root user and www-user is probably not part of the root group.
In short, don't pass -u (and its associated argument) if you want to elevate to root.
Try rewriting the last line of your script to:
sudo -u $ORIENTDB_USER sh -c "/usr/bin/nohup \"$ORIENTDB_DIR\"/bin/server.sh 1> \"$ORIENTDB_DIR\"/log/orientdb.log 2> \"$ORIENTDB_DIR\"/log/orientdb.err &"
If that still doesn't work, then www-user probably doesn't have write permission to /usr/local/orientdb/log (Note that you said /usr/local/orientdb/logs exists but is an empty folder: one of them has a s at the end)