[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: permission of script linked to cron



Haines Brown wrote:
Raj Kiran Grandhi <grajkiran@gmail.com> writes:

Haines Brown wrote:
I have a script, ~/scripts/backup, owned by root, that mounts an
external UPS drive, creates a directory based on date, and backs up my
hard disk with the exception of a few directories.
I created a symlink to /etc/cron.weekly to automate the job, but
because the script is located in user's directory, it runs with user's
permission, and much of the backup has "permission denied".
I am unable to reproduce this. Symbolic links in the /etc/cron.hourly
directory run as root irrespective of where the link points to. In my
case, the scripts were not even owned by root and were in a user's
home directory. Place a link to the following script and examine its
output:

### Start of script
#!/bin/bash
echo "UID=$UID; EUID=$EUID"
env
### End of script

I tried this, and it works. That is, I created a test script owned by
user in ~/brownh/scripts and symlinked it to /etc/chron.hourly (I'm running
Debian Etch), and sure enough, chron sent me this message:

  /etc/cron.hourly/test:
  UID=0; EUID=0
  SHELL=/bin/sh
  PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
  PWD=/
  LANG=en_US.UTF-8
  HOME=/root
  SHLVL=2
  LOGNAME=root
  _=/usr/bin/env

I'm not sure what this suggests. If I do:

        $ ~/scripts/test
        UID=1000; EUID=1000
        SSH_AGENT_PID=8645
        TERM=xterm
        SHELL=/bin/bash
        HUSHLOGIN=FALSE
        WINDOWID=35651597
        USER=brownh
        ...
This suggests that when user runs the script. the script has the
powers of user, but when root runs it (symlink from /etc/cron.hourly)
it runs as root commands. That is, if I am root and do:
        # ~/scripts/backup

I get a complete backup. If I run as user or if cron.weekly runs it by
means of a symlink, it is a partial backup of only those directories
accessible by user.
So I tried to start the script with this snippet:
  pw=<password>
  sudo
  echo $pw
which does not work. I have several questions:

b) Why does the script snippet above not work?
In the snippet above the echo command is run _after_ the sudo command
completes. You probably wanted to pass the password to the standard
input of the sudo command. You can try using a pipe for that, like:

echo $pw|sudo /path/to/your/backup-script

Understood, but the problem is that I'm trying to get the commands in
the backup script to have the permission of root. had I assumed that a
symlink in /etc/cron.weekly pointing to a backup script would have no
permissions problem.
Here's the backup script in its entirely that fails to work in the
sense that cron reports permission denied for directories requring
root permission to cpio. I don't see that the little echo routine does
anything, but I'm putting this backup script symlink into
/etc/cron.hourly to see what happens. pw=<password> echo $pw | sudo

  sudo mount /media/mirror
  dirName=`date +%F`
  sudo mkdir /media/mirror/"$dirName"
  sudo find / -print | egrep -v "^/media|^/proc|^/sys" | cpio -pdmuv /media/mirror/"$dirName" 2>&1 | cat -vt

  echo $pw | sudo
  sudo umount /media/mirror
  exit 0


Hi Haines,

I dunno why cron is running your script as a user. However, the cpio command that is reading the files from the output of find will be running as a normal user. You will probably need to add a sudo before it as well. In any case, it would be cleaner to simply modify sudoers to permit the script to be run as root with no password.

Did you see the response of Andrei to your original message, perhaps you can try that as it involves just adding the following line to your /etc/crontab

47 6 * * 7	root	/path/to/my/script


Raj Kiran



Reply to: