That's dangerous ground to get into, there are always holes in *all* distributions, regardless of how quickly they're fixed. Leaving the defaults running regardless of whether you use them is not the safest course of action on a machine that matters. I can't say for sure that at isn't needed by anything else, all I can say for sure is that I removed a whole bunch of stuff when I first installed including at and I haven't noticed anything complain about at missing yet...
Pat. > Mo, > > Red Hat security is always lousy ;) > > Unlike Red Hat, Debian gets security bugs and such fixed in a timely > manner, especially if you are using the current `unstable' distribution > (which is presently `woody'); `at' should be fine. Be sure to get security > updates from security.debian.org if you do not use unstable... > > Regards, > > Alex. > > --- > PGP/GPG Fingerprint: > EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS/CM>CC/IT d- s:+ a16 C++(++++)>$ UL++++>$ P---() L+++>+ E+>+ W+(-) N o? K? w--() > !O M- !V PS+>+ PE- Y+ PGP t+ !5 X-- !R tv b DI D++ > G>+++ e-- h! !r y > ------END GEEK CODE BLOCK------ > > On Tue, 26 Sep 2000, Mo Zhen Guang (SLDT) wrote: > > > I read of an article about redhat linux security, here is excerption about > > atd > > -------------------- > > This scheduling daemon schedules "jobs" for later execution. You > > could use at to tell atd to run "ps -ef > /root/jay " in two hours, just to > > find out what processes are running then. Unfortunately, there's been a rich > > history of security problems in the at / atd program pair. Fortunately, the > > same basic functionality can be found in crond , which is a wholly necessary > > daemon. Disable atd , and its associated program /usr/bin/at, by running: > > # chkconfig atd off > > # chmod 000 /usr/bin/at > > ----------------------- > > I was wondering if I should do the same on Debian when I never use at > > command , or some other debian packages depend on atd for self maintenance > > so I have to keep it? (when I tried to remove at package with dselect, no > > dependency problem arise) > > > > Thank you > > Mo > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
