> 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 -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
