В Sat, 30 May 2015 11:37:37 +0100 Joāo Ricardo Sares Teles de Matos <[email protected]> пишет:
> 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? I apologize for confusion. On GRUB CLI level there is no difference between "unset" and "empty" indeed - you can only check whether result of variable substitution ($foo) is empty or not and it is empty in both cases. In this particular case grub internally does distinguish between empty and non set ``superusers'' variable. So using set superusers= effectively disables access to CLI and menu editing. > Either of those would warrant a clarification in the manual. > I tried to change description to make it explicit that empty superusers disabled CLI and menu edit. As for variables on CLI - I think it is implicit in that there is no syntax to check whether variable is set. > 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 > >> > _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
