sudo and writing to /var/log
Hi everyone, I'm writing a small script to automate backing up to a remote machine using rsync. As part of the script, I'm directing stdout from rsync to /var/log/b.netbackup.log. The problem I'm having is in actually outputting said stdout. I run all my scripts with user privileges only, escalating to root only those commands within the script that need it. This has various benefits in my eyes: 1. Principle of least privilege; why run a whole script as root when you can just run certain bits of it? 2. No need to error-check UID=0 3. Anyone in the sudoers group can run the script. So normally I just type the script name from the dollar prompt, rather than sudoing it. Inside the script itself, rsync is run with sudo, so as to both read certain files in /etc/ which have 0600 umasks, and also to be able to output to the log file in /var/log. HOWEVER You would think (or at least, I do) that something like "sudo rsync options source destination >> /var/log/logfile" would NOT give you a permission denied error. Similarly with "sudo date > /var/log/logfile". But you would be dead wrong. Running the entire script with sudo (ie, sudo b.netbackup) will work fine, as will running it from a hash prompt. Anyone got any ideas why I can't write to a log file using sudo? Hopefully it isn't something really obvious that will demonstrate my fundamental lack of understanding of how Linux works... Regards, Bnonn
You would think (or at least, I do) that something like "sudo rsync options source destination >> /var/log/logfile" would NOT give you a permission denied error. Similarly with "sudo date > /var/log/logfile". But you would be dead wrong.
Running the entire script with sudo (ie, sudo b.netbackup) will work fine, as will running it from a hash prompt.
That's all correct :)
Anyone got any ideas why I can't write to a log file using sudo? Hopefully it isn't something really obvious that will demonstrate my fundamental lack of understanding of how Linux works..
It may not demonstrate a fundamental lack of understanding, but it is a fairly fundamental point. If I run the command "sudo date > /var/log/logfile", then only 'data' is run within the sudo command. The output redirection to /var/log/logfile is executed within the current bash process - running as the user. All is not lost - run the command AND the redirection from within the sudo command: sudo /bin/bash -c " date > /var/log/logfile" will tell sudo to run bash, and have bash execute the command (or shell snippet) contained inside the following string.
* Daniel Lawson <daniel(a)meta.net.nz> [2005-11-30 03:35]:
All is not lost - run the command AND the redirection from within the sudo command:
sudo /bin/bash -c " date > /var/log/logfile"
That runs an extra shell and the command itself as root though, when all you need root privs for is to open the file. You can avoid such needless privileges using a minimal process to write to the file that takes the destination file as a parameter and opens it itself, instead of using shell redirection. Then you can run *only* that process as root. Un-/fortunately, the common Unix toolbox has a suitable tool, but one that involves a minor annoyance: date | sudo tee /var/log/logfile > /dev/null The annoyance being, of course, that this forces you to pipe STDOUT to the bit bucket. (If you need to append rather than overwrite, tee(1) has an `-a` switch, so that’s also covered.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
On Wed, 2005-11-30 at 05:21 +0100, A. Pagaltzis wrote:
More cool stuff
Thanks, that's pretty cool. It did bug me a bit that I had to call another bash shell, and one of the disadvantages of having haphazardly learned Linux on my own terms is that I was completely unaware of the existence of tee!
participants (3)
-
A. Pagaltzis -
Bnonn -
Daniel Lawson