Hiding the contents of /etc/crontab sounds to me like security through obscurity. There's very little depth to it, and it's more likely to give a false sense of security than anything real. Anyone hardcoding a mysql password in the command line is asking for trouble, regardless of whether /etc/crontab is readable. Once running, It's visible to anyone via tools like ps and procfs. Better to leave the neophyte administrator to figure out how not to put the password or anything else sensitive on the command line, rather than letting them believe that it's secure because the crontab file is not readable. Andrew McNaughton On Tue, 10 Aug 2004, Gustavo A. Baratto wrote: > It is better to have something secure by default. If someone wants to open > up the crontab in /etc/crontab for other users to see it, he/she can do it > on his/her own risk. > Many ppl that are not very familiar with system administration nor security, > but yet manage a server could add cronjobs that could be very harmful to > themselves and they don't know (eg. mysqldump for backups with the password > hardcoded in the command). > > Maybe, the purpose of /etc/crontab is exactly to be a read-by-all file. > That's fine, but in this case, a security warning with BIG letters should be > printed in the very beginning of the file. > > my $0.02 ;) > > > ----- Original Message ----- > From: "Garance A Drosihn" <[email protected]> > To: "Xin LI" <[email protected]>; "Doug Barton" <[email protected]> > Cc: <[email protected]> > Sent: Tuesday, August 10, 2004 12:01 PM > Subject: Re: [PATCH] Tighten /etc/crontab permissions > > >> At 2:10 AM +0800 8/11/04, Xin LI wrote: >>> >>> On Tue, Aug 10, 2004 at 10:02:09AM -0700, Doug Barton wrote: >>>> >>> > Can you elaborate on your thinking? >>> >>> I'm not sure if this is a sort of abusing systemwide crontabs, but >>> the administrators at my company have used them to run some tasks >>> periodicly under other identities (to limit these tasks' privilege), >>> and it provided a somewhat "centralized" management so they would >>> prefer to use systemwide crontab rather than per-user ones. >> >> You could get about the same effect by having them all under root's >> crontab, and then having the entry 'su' to the appropriate userid >> before running. So it is centralized in one crontab (root's), but >> it is protected from prying eyes. >> >>> What do you think about the benefit for users being able to see >>> the system crontab? I think knowing what would be executed under >>> others' identity is (at least) not always a good thing, especially >>> the users we generally don't fully trust... >> >> For generic system tasks, it can be useful to know when they run. >> Maybe this means more to me because I'm actually awake at all odd >> hours of the morning, so I notice the effects of some of those >> runs. My runs of 'cvsup_mirror', for instance. >> >> Basically, I use the system crontab for events where I think it >> is safe for every user to know when the events occur, and use >> other crontabs for the things I want to keep private. Just a >> personal preference thing, obviously. >> >> -- >> Garance Alistair Drosehn = [email protected] >> Senior Systems Programmer or [email protected] >> Rensselaer Polytechnic Institute or [email protected] >> _______________________________________________ >> [email protected] mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to > "[email protected]" >> > > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "[email protected]" > -- No added Sugar. Not tested on animals. May contain traces of Nuts. If irritation occurs, discontinue use. ------------------------------------------------------------------- Andrew McNaughton Living in a shack in Tasmania [email protected] Between the bush and the sea Mobile: +61 422 753 792 http://staff.scoop.co.nz/andrew/cv.doc http://www.scoop.co.nz/ _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"