Bug 1284370 - Grub password broken by update from RHEL7.1 to RHEL7.2
Grub password broken by update from RHEL7.1 to RHEL7.2
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: grub2 (Show other bugs)
7.2
All Linux
high Severity high
: rc
: ---
Assigned To: Peter Jones
Release Test Team
: ZStream
Depends On:
Blocks: 1290089
  Show dependency treegraph
 
Reported: 2015-11-23 02:48 EST by bugreports2005
Modified: 2016-11-03 23:59 EDT (History)
8 users (show)

See Also:
Fixed In Version: grub2-2.02-0.31.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1290089 (view as bug list)
Environment:
Last Closed: 2016-11-03 23:59:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2097151 None None None 2015-12-17 23:47 EST

  None (edit)
Description bugreports2005 2015-11-23 02:48:23 EST
Description of problem:

The Grub password originally set in RHEL7.1 ceases to work when updating to RHEL7.2.


Version-Release number of selected component (if applicable):

grub2-tools-2.02-0.29.el7.x86_64


How reproducible:

Should be.


Steps to Reproduce:
1. Install RHEL7.1 with a grub password, for example by using this in kickstart:

bootloader --iscrypted --password=grub.pbkdf2.sha512.10000.<and so on>

It is written to /etc/grub.d/01_users something like this:

cat << "EOF"
set superusers="root"
export superusers
password_pbkdf2.sha512.10000.<and so on>
EOF

2. Update to RHEL7.2
3. Try to make use of the password in grub


Actual results:

It doesn't work.


Expected results:

It works.


Additional info:

The preinstall scriptlet of grub2-tools-2.02-0.29.el7.x86 checks for a password hash in /etc/grub.d/01_users and creates a user.cfg where it places it in a variable called GRUB_PASSWORD.

The new /etc/grub.d/01_users from the same package then reads the created user.cfg, but unfortunately looks for a variable GRUB2_PASSWORD instead. This is not set, so grub won't see the old password.
Comment 7 Tomas Hoger 2015-12-04 05:03:38 EST
(In reply to bugreports2005 from comment #0)
> Actual results:
> 
> It doesn't work.

Just to be explicit, this means: grub2 still prompts for password, but does not accept valid / previously working password any more; rather than: grub2 no longer prompts for password.

Please comment if you're seeing different results.
Comment 16 Ken Long 2015-12-09 08:47:56 EST
I'm seeing this problem also.  On my RHEL 7.1 systems that were upgraded to RHEL 7.2, the /etc/grub.d/01_users was replaced, but no user.cfg file was ever created.  Net result is that now I can reboot my servers and get into the grub menu and do anything I want with no password.

My 01_users file used to contain:

cat <<EOF
set superusers="admin"
password_pbkdf2 admin grub.pbkdf2.sha512.10000.3...<redacted>...3
EOF


I have an active RedHat case on this. Case # 01547015
Comment 18 Tomas Hoger 2015-12-09 17:45:06 EST
(In reply to Ken Long from comment #16)
> I'm seeing this problem also.  On my RHEL 7.1 systems that were upgraded to
> RHEL 7.2, the /etc/grub.d/01_users was replaced, but no user.cfg file was
> ever created.  Net result is that now I can reboot my servers and get into
> the grub menu and do anything I want with no password.
> 
> My 01_users file used to contain:
> 
> cat <<EOF
> set superusers="admin"
> password_pbkdf2 admin grub.pbkdf2.sha512.10000.3...<redacted>...3
> EOF

The migration script looks for "password_pbkdf2 root", i.e. what anaconda installer generates.  As you used a different user name, user.cfg did not get created.

I think your options to consider:

- Use grub2-setpassword to create user.cfg and user "root" username in grub instead of "admin".  The new rpm-provided 01_users assumes the password in user.cfg is for user root and does not allow specifying a different one.

- If you prefer to keep using "admin", restore your old 01_users under a different name that does not conflict with other scripts in /etc/grub.d that are provided by grub2 packages.  Regenerated grub.cfg with grub2-mkconfig.

Out of curiosity, did you run grub2-mkconfig manually during the upgrade form 7.1 to 7.2?  It's not normally run during such upgrade.
Comment 19 Ken Long 2015-12-09 18:07:20 EST
Actually, now that you mention it, I believe I did run it manually on the one that I'm using for testing.  I ran it when I was initially troubleshooting.  Wouldn't that command get run again the next time a kernel is updated?  Either way, I hate leaving something dangling out there that may break me the first time some script runs that I wasn't expecting to run.

As for the username, I added the password later when I was CIS hardening the boxes, so it was never done by anaconda.  I just arbitrarily picked a name that wasn't quite as obvious as "root", but that's not any sort of requirement.

I just went on my test machine and ran grub2-setpassword and let it set the password and rebooted and used the username "root" and that worked great, so that's definitely a viable work around since I have less than a dozen systems.  

If you need me to test any more general fixes, let me know.

Thank you for your help!
Comment 20 Tomas Hoger 2015-12-09 18:32:28 EST
(In reply to Ken Long from comment #19)
> Actually, now that you mention it, I believe I did run it manually on the
> one that I'm using for testing.  I ran it when I was initially
> troubleshooting.  Wouldn't that command get run again the next time a kernel
> is updated?

The information I got is that grub2-mkconfig is only run during installation.  new-kernel-pkg/grubby is used during kernel upgrades, which does not invoke grub2-mkconfig.  This should be the reason why the issue was not initially reproduced successfully after it was reported.

> If you need me to test any more general fixes, let me know.

Proposed fixes address issues with migration of password from anaconda generated 01_users to user.cfg and do not aim to address handling of custom files.  There's also separate work on getting documentation corrected and updated to reflect changes in 7.2.
Comment 21 Ken Long 2015-12-10 09:17:56 EST
Fair enough.  Although, that leads to the larger question that if grub2-mkconfig is ONLY run during installation, then when would the new 01_users and the  automatically created user.cfg files EVER be used?

But back to the more immediate issue, my only suggestion would be that since users may have modified 01_users with custom users, that you check and if the file has been customized from the original, treat it like any other configuration file and rather than replacing it, just create the new file as 01_users.rpmnew with a comment line at the top telling how to create the user.cfg file.  As long as the old config file isn't incompatible with grub in 7.2, I would tend towards the "do no harm" approach.  Just a suggestion.
Comment 22 Tomas Hoger 2015-12-11 10:33:43 EST
(In reply to Ken Long from comment #21)
> Fair enough.  Although, that leads to the larger question that if
> grub2-mkconfig is ONLY run during installation, then when would the new
> 01_users and the  automatically created user.cfg files EVER be used?

Apparently, mkconfig run is needed for user.cfg configuration to work.  It seems the upgrade case was not fully considered.

> But back to the more immediate issue, my only suggestion would be that since
> users may have modified 01_users with custom users, that you check and if
> the file has been customized from the original, treat it like any other
> configuration file and rather than replacing it, just create the new file as
> 01_users.rpmnew with a comment line at the top telling how to create the
> user.cfg file.  As long as the old config file isn't incompatible with grub
> in 7.2, I would tend towards the "do no harm" approach.  Just a suggestion.

This is bit of a corner case, as 01_users was not previously part of the package, it was only generated during system installation.  Hence there was no original, not customized version from RPM point of view.  There was not supported tools for updating or customizing 01_users after installation.  The migration script only covers the specific format generated by anaconda.
Comment 28 Pavel Holica 2016-08-09 03:22:29 EDT
Reproduced on RHEL-7.2 GA x86_64 Server (upgraded from RHEL-7.1)
Verified fix on RHEL-7.3-20160729.1 (upgraded for x86_64 Server with grub2-2.02-0.41.el7.x86_64
Comment 30 errata-xmlrpc 2016-11-03 23:59:40 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2336.html

Note You need to log in before you can comment on or make changes to this bug.