FS#30870 - [grub-common] menuentries need "--unrestricted" parameter
Attached to Project:
Arch Linux
Opened by Tobias Hunger (hunger) - Thursday, 26 July 2012, 21:26 GMT
Last edited by Laurent Carlier (lordheavy) - Friday, 21 June 2013, 05:46 GMT
Opened by Tobias Hunger (hunger) - Thursday, 26 July 2012, 21:26 GMT
Last edited by Laurent Carlier (lordheavy) - Friday, 21 June 2013, 05:46 GMT
|
Details
Description:
Shortly before grub2 was made final there was a change with regards to how passwords in grub.cfg are handled. When setting a username/password in grub.cfg you used to be able to boot the defined entries and only need to provide the password to edit them. This was changed to always asking for a password, even when just selecting predefined entries. This was a nasty surprise during the upgrade of my headless server box:-) To allow everybody to boot predefined entries you now need to provide the "--unrestricted" parameter to all menuentry lines. Could those get added by default, please? Editing all the files in /etc/grub.d/ is rather error-prone:-) Ideally you could define the users allowed to boot entries by default in /etc/default/grub (with "every user" being the default) :-) Additional info: * grub-bios 2.00-1, grub-common 2.00-1 * A password set up as described in https://wiki.archlinux.org/index.php/GRUB#Security Steps to reproduce: 1) Set a password 2) regenerate grub.cfg using grub-mkconfig 3) Reboot. |
This task depends upon
Can you confirm that adding --unrestricted to the menuentry lines only enables booting without password but the actual editing is still password protected?
https://www.gnu.org/software/grub/manual/grub.html#Security says that once "superusers" are set up the use of the command line (which does incl. editing of all menu entries as I understand it) is only allowed to those people listed as superusers (see 4. paragraph).
What I did *not* check is whether "--unrestricted" has side effects when no password/superusers are set up. But from how I understand the documentation it should not.
That is out of scope for this bug report: The issue is that the config created after adding a password (as described by the arch wiki as well as the grub manual) does not work as expected and as it did till before grub 2.0rc. IIRC the RC release started to require the --unrestricted to continue to automatically boot any entry.