Re: [tlug] Running an Exec file with Cron

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Charles" == Charles Muller <acmuller@example.com> writes:

    >> crontabs are kept in a spool area private to cron, and only
    >> root (ie, the suid crontab program) can put them there.

    Charles> This also clarifies something that I needed to know,
    Charles> because I had read in one of the explanatory pages that
    Charles> some systems allowed the regular user to do crontab -e
    Charles> (and on my system, I can do it as regular user, and the
    Charles> file saves as usual in /etc, but it doesn't seem to run).

That seems wrong.  AFAIK, Linux systems all use Vixie cron, which
supplies an suid[1] crontab program.  All it does is (1) cp your crontab
to /tmp, (2) start your editor with the copy in a buffer, and (3) cp
it back when you're done.  As BOTi mentioned, the spool area is under
/var on Debian; it's not part of the system config, so it really
doesn't belong in /etc.  Here's mine:

bash-2.05a$ su -c 'ls -laR /var/spool/cron/'
Password: 
/var/spool/cron/:
total 5
drwxr-xr-x    5 root     root         1024 Sep 13  2001 .
drwxr-xr-x   12 root     root         1024 Oct 26  2001 ..
drwx------    2 daemon   daemon       1024 Jan 21 20:37 atjobs
drwx------    2 daemon   daemon       1024 Sep 20  2001 atspool
drwxr-xr-x    2 root     root         1024 May 24 23:47 crontabs

/var/spool/cron/atjobs:
total 3
drwx------    2 daemon   daemon       1024 Jan 21 20:37 .
drwxr-xr-x    5 root     root         1024 Sep 13  2001 ..
-rw-------    1 daemon   daemon          6 Sep 20  2001 .SEQ

/var/spool/cron/atspool:
total 2
drwx------    2 daemon   daemon       1024 Sep 20  2001 .
drwxr-xr-x    5 root     root         1024 Sep 13  2001 ..

/var/spool/cron/crontabs:
total 4
drwxr-xr-x    2 root     root         1024 May 24 23:47 .
drwxr-xr-x    5 root     root         1024 Sep 13  2001 ..
-rw-------    1 root     steve        1275 May 24 23:47 steve
bash-2.05a$ 

Note I had to su to see cron's directories, except for the user
crontabs subdirectory.

For the crontab "steve" in the crontabs subdirectory, the owner is
root; only root can read and write the crontab for user steve.  I'm
not sure if there's any significance to the group "steve", I think
with those perms it's a don't-care so crontab just doesn't bother to
sgid or chgrp the file.

If you don't have a "chuck" crontab somewhere, then somehow you're not
convincing crontab -e to edit the right thing.

    Charles> So if I can only run crontab as SU, then I guess that I

No, there's no need to run crontab as the root user; you can just edit
the cron spool file for root, or the system spool file in  /etc/crontab.

    Charles> should just have to settle with the fact that tarballs
    Charles> and copied files will all end up having root permissions?

No.  If your system provides a crontab program, then its only purpose
is to allow ordinary users to read and write files that would
otherwise be prohibited to them.  It doesn't provide any editing
capability itself.

If it is not editing a crontab in the spool area [the Debian manpage
says:

       cron searches its  spool  area  (/var/spool/cron/crontabs)
       for  crontab  files  (which  are  named  after accounts in
       /etc/passwd); crontabs found are loaded into memory.]

then something's broken.  With Red Hat it seems unlikely that
something this broken would go unnoticed.  It's quite possible that
Red Hat puts the spool area somewhere else,

strings `which crontab` | fgrep /cron

should turn it up.  (User crontabs may be in a subdirectory.)

Footnotes: 
[1]  SUID == "Set User ID" to the owner of the file.  If root owns it,
then the program is executed with root permissions.  Thus crontab can
copy from anywhere to anywhere else, but it's hardwired to copy from
the spool area to /tmp, and nothing else.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py