Is there no difference between an "unset variable" and a variable set to an
empty string, or are both cases just treated the same in this particular
situation?
Either of those would warrant a clarification in the manual.
On May 30, 2015 5:46:44 AM GMT+01:00, Andrei Borzenkov <[email protected]>
wrote:
>В Sat, 30 May 2015 01:23:32 +0100
>Joāo Ricardo Sares Teles de Matos <[email protected]> пишет:
>
>> On second thought...
>> "If ‘superusers’ is set, then use of the command line is
>automatically restricted to superusers."
>>
>> Setting an empty superusers list and adding --unresticted to your
>entries is probably what you want.
>>
>
>Empty $superusers is treated the same as no $superusers. GRUB
>translates legacy menu.lst clause into "superusers=legacy" to assign
>it /some/ value. In general, just set superusers to any non-empty
>string and do not define any user and password.
>
>> On May 30, 2015 1:05:28 AM GMT+01:00, "Joāo Ricardo Sares Teles de
>Matos" <[email protected]> wrote:
>> >It's right here:
>> >https://www.gnu.org/software/grub/manual/grub.html#Security
>> >Set a superuser that can't actually be used and use --unrestricted
>on
>> >the entries.
>> >
>> >How to set up an "unauthenticatable" superuser is my question.
>> >Maybe setting an invalid password hash with password_pbkdf2 or just
>not
>> >setting the user's password will suffice.
>> >
>> >On May 29, 2015 10:28:17 PM GMT+01:00, "Boyce, Kevin P. (AS)"
>> ><[email protected]> wrote:
>> >>All,
>> >>
>> >>I am hoping someone can help me with a grub2 configuration
>question.
>> >I
>> >>
>> >>would like to be able to secure grub menu entries from being
>modified.
>> >>I do not want to have to enter a password to boot the system (which
>
>> >>doesn't appear to be the current behavior of grub2 when set
>> >>superusers="root" directive is used).
>> >>I do not want to have to create users and associated passwords
>(null
>> >>password is OK).
>> >>
>> >>I would like everyone to be able to select either one of these two
>> >boot
>> >>
>> >>entries without the need for a password, but i do not want them to
>be
>> >>able to enter command mode or edit mode in which they could boot
>> >single
>> >>
>> >>user mode (my Rescue enviroment is being customized for recovery
>> >>purposes).
>> >>
>> >>My bootloader and configuration will be permanently installed in a
>> >>read-only device like ROM and never changed. I use the configfile
>> >>directive to point to the real bootloader configuration on a
>different
>> >
>> >>device I want to use.
>> >>
>> >>Here is my current config file, documentation on grub2 security
>seems
>> >a
>> >>
>> >>little lacking. I recall being able to achieve this behavior by
>using
>> >
>> >>the lock directive in legacy-grub.
>> >>Any help would be appreciated.
>> >>
>> >>Thanks,
>> >>Kevin
>> >>
>> >># Load GPT Partition Support
>> >>insmod part_gpt
>> >>
>> >># Load XFS File System Support
>> >>insmod xfs
>> >>
>> >># Load EXT File System Support
>> >>insmod ext2
>> >>
>> >># Set a timeout before we pick the default
>> >>set timeout=7
>> >>
>> >># Set the default boot entry
>> >>set default="0"
>> >>set fallback="1"
>> >>
>> >># Don't want any accounts that can bypass either one of these two
>> >>entries
>> >>set superusers=""
>> >>
>> >># Default boot entry redirecting to config file on RAID
>> >># Secure without granting users permission to modify
>> >>menuentry "Redirect Boot to RAID Device" --users "" {
>> >> search --no-floppy --set=root --label RAID
>> >> configfile /.firmware/boot.cfg
>> >>}
>> >>
>> >># Create an entry for loading troubleshooting environment
>> >># Secure without granting users permission to modify this entry
>> >>menuentry "Rescue" --users "" {
>> >> search --no-floppy --set=root --label RESCUE
>> >> linux /vmlinuz rescue
>> >> initrd /initrd.img
>> >>}
>> >>
>> >>_______________________________________________
>> >>Help-grub mailing list
>> >>[email protected]
>> >>https://lists.gnu.org/mailman/listinfo/help-grub
>> >
>> >--
>> >Typed with a virtual keyboard. Please excuse any blunders.
>> >
>>
>>------------------------------------------------------------------------
>> >
>> >_______________________________________________
>> >Help-grub mailing list
>> >[email protected]
>> >https://lists.gnu.org/mailman/listinfo/help-grub
>>
--
Typed with a virtual keyboard. Please excuse any blunders._______________________________________________
Help-grub mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-grub
