2009/8/13 Mertens, Bram <mertensb@xxxxxxxxxxxx> > > > > > Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek > VAT BE 0406.024.281, RPR Mechelen, ING 310-0092504-52, IBAN : BE64 3100 > 0925 0452, SWIFT : BBRUBEBB > > -----Original Message----- > > From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list- > > bounces@xxxxxxxxxx] On Behalf Of ESGLinux > > Sent: donderdag 13 augustus 2009 12:23 > > To: General Red Hat Linux discussion list > > Subject: Re: disable automatic updates > [:::] > > > you could grant them permission to do anything as any user on the > > system. > > > While this is NOT secure since it allows them to circumvent the > > mechanism > > > it could help if all you want is a log of which commands were > > executed. > > > This is off course given that you can agree to not use the > > loopholes. > > > > > > one question, do you think is it a good idea to put the users in the > > wheel > > group? > > or > > is better another aproach? > > I can't tell because I don't know your environment. Putting users in the > wheel group means enabling sudo is very straightforward. If you use another > group or groups you'll have some additional overhead in editing the sudoers > file. > On the other hand using separate groups allows you to restrict access > further, which you should strive at. Especially since it looks like you're > fellow admins are not taking their responsibility seriously. > > > > To figure out what happened I suggest that you look at your cron log > > for > > > Jul 10 at about the time mentioned in the yum log. > > > If you have a cron job installing updates automatically you should > > find it > > > there. Then hopefully from there you can figure who/how this was > > scheduled > > > and how to disable it. > > > > > > > as I expected there isn´t any reason to think that it was an automatic > > update. I suppose someone applied the updates without much care and now > > he/she has shame to say it. ;-) > > Actually perhaps this can be to your advantage. Given the fact that you > are clearly eager to find out the responsible I assume your business lost > money on this. Perhaps you should consider using this as leverage to > convince your manager that tighter security policies are needed. > > Fixing something or preventing something from happening again usually does > more good than blaming whoever made a (perhaps honest) mistake. > > Regards > > Bram > Hi, Thanks for your answers, I´ll take all of this in account. I´m going to try to convince my boss to pay more attention to security. (I´ll need a lot of luck ;-) ) Greetings ESG > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subjecthttps://www.redhat.com/mailman/listinfo/redhat-list
