Bug 1288108

Summary: SysAdminGuide: grub2 password protection section should be updated
Product: Red Hat Enterprise Linux 7 Reporter: Tomas Hoger <thoger>
Component: doc-System_Administrators_GuideAssignee: Maxim Svistunov <msvistun>
Status: CLOSED CURRENTRELEASE QA Contact: ecs-bugs
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.2CC: msvistun, rhel-docs, sgaikwad, thoger
Target Milestone: rcKeywords: Documentation
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-08 12:40:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomas Hoger 2015-12-03 14:44:29 UTC 
Document URL:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-GRUB_2_Password_Protection.html#sec-Preserving_the_Setup_after_GRUB_2_Updates

Section Number and Name:

24.6. GRUB 2 Password Protection

Describe the issue:

I think there are few issues:

- Document mentions that 01_users should be created if it wasn't during system installation.  It should also mention that the file needs to be made executable to actually get used during grub2-mkconfig.  Similarly, it should suggest safe permissions (e.g. 700) to avoid having password in a world-readable file.

- Well, the above is no longer relevant on 7.2, as 01_users is now packaged and I do not think it's expected to have username / passwords defined in it directly any more.

Instead, the document should mention grub2-setpassword, which was added  in 7.2 (see bug 985962), as the default 01_users now has commands to read password from /boot/grub2/user.cfg generated by that command.

- Document describes how to create custom password protected boot menu entries in 40_custom.  However, it's probably not what most users care about or want to do.  I think the document should explicitly describe impact the creation of superuser has on the default entries generated by the 10_linux (i.e. with superuser defined, it's no longer possible to edit boot command line without providing password, but any boot meny entry can be selected, as all entries generated by 10_linux have --unrestricted).  The following kbase describes how to make grub2 require password during boot:

https://access.redhat.com/solutions/979643