Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 415713 - sys-boot/grub-2.00_beta5 asks for password on unrestricted menuentries
Summary: sys-boot/grub-2.00_beta5 asks for password on unrestricted menuentries
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Mike Gilbert
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-13 08:55 UTC by Lars Wendler (Polynomial-C) (RETIRED)
Modified: 2012-05-14 16:46 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
40_custom (40_custom,1.21 KB, text/plain)
2012-05-13 08:55 UTC, Lars Wendler (Polynomial-C) (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2012-05-13 08:55:43 UTC
Created attachment 311593 [details]
40_custom

Hi,

since I upgraded from gub-2.00_beta3 to beta5 I cannot boot any menuentry without getting asked for a password.
I've set up a superuser and password so people cannot mess with the menuentries themselves but none of the menuentries are restricted (no --user option is given) so users can boot the menuentries as they wish. This worked flawlessly with grub-2.00_beta3 but not anymore with beta5.

I'm only using /etc/grub.d/40_custom file to generate the grub config file, which I've attached here.
Comment 1 Martin Väth 2012-05-13 10:39:32 UTC
I can confirm that.
I am nor generating grub.cfg at all, and the same grub.cfg which was
working with earlier grub-betas now requires a password for every entry,
not only for the protected ones.
Comment 2 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2012-05-13 11:40:46 UTC
Alright this seems to be an intentional change done by upstream:

# bzgrep -A 2 "Default to restricted" /usr/share/doc/grub-2.00_beta5/ChangeLog.bz2 
        * grub-core/commands/legacycfg.c (legacy_file): Default to restricted
        entries.
        * grub-core/commands/menuentry.c (grub_cmd_menuentry): Likewise.


So adding "--unrestricted" to the menuentries is fixing the issue.

Mike, how about adding some kind of elog message to >=grub-2.00_beta5 reflecting this change?
Comment 3 Mike Gilbert gentoo-dev 2012-05-13 15:05:32 UTC
I understand that this was probably a bit frustrating. However, I have a feeling that a small number people use this feature, so an elog message would just be noise that may actually confuse some users.

Can you provide a way to identify whether a user is actually affected by this change?
Comment 4 Martin Väth 2012-05-14 06:40:40 UTC
Now that I know that it is not a bug but an interface change,
I suggest to close it as INVALID: Users of beta software have
to expect such changes, and new users will not be affected.

In fact, the --unrestricted example is now given on the info page.

(BTW: In emacs info, most automatically generated entries want to
load a nonexistent grub info file instead of the valid grub2 info file,
so I guess something wrong with the info DIR generation yet? But this is
almost not worth to open a new bug...).

Anyway:

(In reply to comment #3)
> Can you provide a way to identify whether a user is actually affected by
> this change?

Probably most reliable is something like
grep -q superusers /boot/grub2/grub.cfg /etc/grub.d/* && ewarn ...
Comment 5 Mike Gilbert gentoo-dev 2012-05-14 16:46:37 UTC
(In reply to comment #4)
> (BTW: In emacs info, most automatically generated entries want to
> load a nonexistent grub info file instead of the valid grub2 info file,
> so I guess something wrong with the info DIR generation yet? But this is
> almost not worth to open a new bug...).

I don't use emacs, so I have no way to test this. Can the issue be reproduced using the normal info command?

There is a sed call in grub-1.99-r2.ebuild that looks like it may have resolved this; however, I think this broke the install target in the build system so I removed it.

Please file a separate bug and preferably provide a patch if you would like this to be fixed.