[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: disable automatic updates



2009/8/13 Mertens, Bram <mertensb mazdaeur com>

> >
>
>
> 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 redhat com [mailto:redhat-list-
> > bounces redhat com] 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 redhat com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]