grub-devel
[Top][All Lists]
Advanced

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

Re: chmod of generated grub.cfg


From: Robert Millan
Subject: Re: chmod of generated grub.cfg
Date: Thu, 10 Sep 2009 20:56:52 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, Sep 08, 2009 at 04:51:41PM +0200, Felix Zielcke wrote:
> Am Dienstag, den 08.09.2009, 16:48 +0200 schrieb Robert Millan:
> > On Sun, Sep 06, 2009 at 07:22:36PM +0200, Vladimir 'phcoder' Serbinenko 
> > wrote:
> > > On Sun, Sep 6, 2009 at 3:38 PM, Colin Watson<address@hidden> wrote:
> > > > On Sun, Sep 06, 2009 at 02:29:03PM +0200, Felix Zielcke wrote:
> > > >> Currently grub-mkconfig uses chmod 444 on the newly generated grub.cfg
> > > >> Wouldn't it be better to use 400 now that we have plaintext password
> > > >> support?
> > > >> Or should we add support for a GRUB_CHMOD variable so users can 
> > > >> override
> > > >> this setting as they please?
> > > >
> > > > I'd prefer to see this done only if they set a password. A GRUB_CHMOD
> > > > variable seems overkill, though.
> > > Is there a reason a non-root would like to look at grub.cfg on
> > > production system? Developers can always override chmod. If there is
> > > no real reason for non-root to look into grub.cfg I would follow the
> > > best friend in security considerations called "paranoia" and just use
> > > mode 400
> > 
> > I like the idea of using 0400 right away, for simplicity.
> > 
> > OTOH, world-readable grub.cfg is useful, at least in Debian, because
> > reportbug includes this file in bug reports.
> > 
> > But if it's only useful for Debian, we shouldn't let this change our
> > agenda (ah, the conflict of wearing two hats...).
> > 
> 
> So in upstream we change it to 400 + warning and for Debian we use my
> last patch?

Ok.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]