From owner-freebsd-hackers Mon Jul 1 06:44:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA27686 for hackers-outgoing; Mon, 1 Jul 1996 06:44:29 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA27675 for ; Mon, 1 Jul 1996 06:44:27 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA15109; Mon, 1 Jul 1996 08:39:55 -0500 From: Joe Greco Message-Id: <199607011339.IAA15109@brasil.moneng.mei.com> Subject: Re: no subject (file transmission) To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 1 Jul 1996 08:39:54 -0500 (CDT) Cc: jkh@time.cdrom.com, pechter@shell.monmouth.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199606271804.UAA02454@uriah.heep.sax.de> from "J Wunsch" at Jun 27, 96 08:04:32 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As Jordan K. Hubbard wrote: > > > > 2. Declare the BSD method (the REAL original crontab) the winner. > > > > I think this is probably our best bet. > > Objection. I voted against /etc/crontab back in the old days, and i'm > still against it (and always kill it as soon as i've installed a > system). I tend to see it as a mistake too... new sysadmins do a "crontab -e" as root and get.. nothing. :-( I see a benefit to having a method that allows the sysadmin to specify cron entries for users that (1) the user cannot change and (2) are centrally administered. > There's only a few things where i'm stating SysV to have the better > approach, but per-user crontabs certainly belong into this category. > > Remember, the original BSD crontab was even more braindead in that it > didn't allow crontab entries for users other than root, and the > current /etc/crontab would make a mess for crontab(1) to allow for > per-user cron commands, while the existing approach with one file per > user is there && has proven to work. On the opposite, i don't see > anything /etc/crontab would gain us that /var/cron/tabs/ doesn't > already give us as well. (Not counting nostalgic feelings. :) Cron entries "forced" upon a user. > Despite of this, i consider a world-readable /etc/crontab a BIG > security hole. Read "The Cuckoo's egg" for why intruders do like to > know when exactly system maintenance jobs are about to run... Yes, /etc/crontab and /var/cron/log* need to be protected.. :-) even so one can often dig appropriate hints out of /var/log/maillog... I would be happier with /etc/crontab if the crontab command at least noted that there were entries for this user in /etc/crontab (perhaps adding them as comments). That has its own problems. I would be happiest if we left /etc/crontab for the experienced admins but put the current contents in /var/cron/tabs/root... that also happens to be the least intrusive option, and also more secure since /etc/crontabs is readable.. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968