Date: Wed, 17 Jan 2001 09:32:04 +0200 From: Neil Blakey-Milner <nbm@rapier.smartspace.co.za> To: Greg Black <gjb@gbch.net> Cc: Dan Nelson <dnelson@emsphone.com>, Michael Bacarella <mbac@mmap.nyct.net>, hackers@FreeBSD.ORG Subject: Re: Permissions on crontab.. Message-ID: <20010117093204.A8964@rapier.smartspace.co.za> In-Reply-To: <nospam-3a6543f7831566c@maxim.gbch.net>; from gjb@gbch.net on Wed, Jan 17, 2001 at 05:04:23PM %2B1000 References: <20010117001842.A28301@mmap.nyct.net> <nospam-3a652ec18b151ad@maxim.gbch.net> <20010117000313.A28355@dan.emsphone.com> <nospam-3a6543f7831566c@maxim.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed 2001-01-17 (17:04), Greg Black wrote:
> > In the last episode (Jan 17), Greg Black said:
> > > Michael Bacarella wrote:
> > > > Why is crontab suid root?
> > > >
> > > > I say to myself "To update /var/cron/tabs/ and to signal cron".
> > > >
> > > > Could crontab run suid 'cron'?
> > > >
> > > > If those are the only two things it needs to do, run cron as gid
> > > > 'cron' and make /var/cron/tabs/ group writable by 'cron'.
> > >
> > > It has to run jobs as the correct user and must be able to setuid
> > > accordingly.
> >
> > Not quite. As far as I can tell, crontab is setuid root for the sole
> > purpose of being able to write to /var/cron/tabs. Cron checks the
> > timestamp on the directory every minute, so crontab doesn't have to
> > signal it for changes to get noticed.
>
> > If you're paranoid, you can
> > probably "chgrp cron /var/cron/tabs" and make crontab setgid cron
> > without any ill effects. Cron itself must stay setuid root, of course,
> > so it can run user crontabs as that user.
>
> Dropping the setuid bit on crontab in favour of a setgid cron
> alternative also means changing the permissions on the
> /var/cron/tabs directory which is currently only accessible to
> root. I'm not sure I would want anybody else to have access
> there. But it would probably work OK.
You need only add group read and write permissions for the crontab
group. Since noone is in the crontab group, unless they invoke crontab,
noone will be gaining any "extra" privilege. I also toyed with making
the directory sticky, and adding sanity checks to cron to not invoke
tabs not owned by the user they refer to or root, or at least give
warnings.
FWIW, I had patches to convert 'at' and 'crontab' to being sgid-at
and sgid-crontab ('at' has some really ugly macros that luckily aren't
needed again). I'll probably be doing them again, now that my time is
more sane.
Neil
--
Neil Blakey-Milner
nbm@smartspace.co.za
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010117093204.A8964>