On Fri, Apr 23, 2010 at 06:59:18PM +0200, Christian Kastner wrote: > >> Currently, it is assumed that because only root can modify /etc/cron.d, > >> all files in there must be valid, due to root's higher level of diligence. > >> > >> One could argue about whether this is too restrictive, and whether one > >> could at least partially run broken crontabs, namely the entries up to > >> the first syntax error (these would hardly be a security issue). I would > >> strongly disagree with this because, as said above, if there are broken > >> crontabs in /etc/cron.d, you're doing something wrong. > > > > I do not believe it's good for a system to assume that root has a high level > > of diligence :) > > Neither do I (by experience), but that's the way things are. root -- by > definition -- enjoys absolute trust, and if that trust is placed in the > wrong hands, there's not much we can do about it. In our case, we > acknowledge the error and log to syslog. > > Let me give you another example: this is also why we allow symlinks in > /etc/cron.d. Because only root can create those, we simply assume > (again) that root knows what she's doing. We just before some basic > checks on the target, such as ownership and permissions. > > I believe that watering down this level of trust for the sake of the > trust-unworthy would be misguided.
I'm not saying don't trust the admin, I'm saying nag him when you see that he has in fact made a fatal error and it persists. > >>> Thanks. Will it show up whenever it is disabled, i.e. will I have a > >>> chance to actually see the message post res? > >> I'm not sure I quite follow, but generally speaking, the message will be > >> logged to syslog once, after which logcheck or whatever can pick it up. > > > > I'm guessing this is the problem - it reads the change once (after the > > file's timestamp/size change), it barfs, and then it keeps ignoring the > > unchanged file with a broken line until you touch it again. > > Yes. This is a side effect of a power-management-related feature, > indented to reduce disk spin-ups on laptops. This is then a horrible side-effect. If there is a fatal error in user-generated data, be it a security issue or a typo, the admin *needs* to be told about it. It is more important to tell them than it is to conserve battery power, even on laptops. It doesn't have to happen every minute, but at the very least there can be a daily job that sends the list of broken crontabs to the root mailbox. -- Josip Rodin Racunalno-informacijski sustavi i servisi CARNet - Croatian Academic and Research Network J. Marohnica 5, 10000 Zagreb, Croatia tel. +385 1 66 61 61 6 http://www.carnet.hr/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
