From here on out, the steps are the same for both the CentOS and the Ubuntu virtual machines, except for the following:

• On your Ubuntu machine, the grub.cfg file is in the /boot/grub/ directory.  On your CentOS machine, it's in the /boot/grub2/ directory.
• On Ubuntu, the /boot/grub/ and /etc/grub.d/ directories are world-readable. So, you can cd into them as a normal user. 
• On CentOS, the /boot/grub2/ and /etc/grub.d/ directories are restricted to the root user. So, to cd into them, you'll need to log in to the root user's shell. Alternatively, you can list the contents from your normal user shell with sudo ls -l, and you can edit the files you need to edit with sudo vim /boot/grub2/grub.cfg or sudo vim /etc/grub.d/40_custom. (Substitute your favorite editor for vim.)
• On Ubuntu, the command to create a password hash is grub-mkpasswd-pbkdf2. On CentOS, the command is grub2-mkpasswd-pbkdf2.

With these slight differences in mind, let's get started.

The first thing you'll do is to create a password hash for your new users:

• On Ubuntu:

        grub-mkpasswd-pbkdf2

• On CentOS:

        grub2-mkpasswd-pbkdf2

Next, open the /etc/grub.d/40_custom file in your text editor and add a line for your new user, along with the password hash that you just created. The line should look something like this:

password_pbkdf2 goldie grub.pbkdf2.sha512.10000.225205CBA2584240624D077ACB84E86C70349BBC00DF40A219F88E5691FB222DD6E2F7765E96C63C4A8FA3B41BDBF62DA1F3B07C700D78BC5DE524DCAD9DD88B.9655985015C3BEF29A7B8E0A6EA42599B1152580251FF99AA61FE68C1C1209ACDCBBBDAA7A97D4FC4DA6984504923E1449253024619A82A57CECB1DCDEE53C06

Note that this is all one line that wraps around on the printed page.

What you're supposed to do next is to run a utility that will read all of the files in the /etc/grub.d/ directory along with the /etc/default/grub file and that will then rebuild the grub.cfg file. But, on CentOS, that utility doesn't work correctly. On Ubuntu, it does work correctly, but it will overwrite any changes that you might have already made to the grub.cfg file. So, we're going to cheat.

Open the grub.cfg file in your text editor:

• On Ubuntu:

        sudo vim /boot/grub/grub.cfg

• On CentOS:

        sudo vim /boot/grub2/grub.cfg

Scroll down until you see the ### BEGIN /etc/grub.d/40_custom ### section. In this section, copy and paste the line that you just added to the 40_custom file. This section should now look something like this:

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
password_pbkdf2 "goldie" grub.pbkdf2.sha512.10000.225205CBA2584240624D077ACB84E86C70349BBC00DF40A219F88E5691FB222DD6E2F7765E96C63C4A8FA3B41BDBF62DA1F3B07C700D78BC5DE524DCAD9DD88B.9655985015C3BEF29A7B8E0A6EA42599B1152580251FF99AA61FE68C1C1209ACDCBBBDAA7A97D4FC4DA6984504923E1449253024619A82A57CECB1DCDEE53C06
### END /etc/grub.d/40_custom ###

Finally, you're ready to password-protect the individual menu entries. And here, I've discovered yet another difference between Ubuntu and CentOS.

In all of the menu entries for CentOS, you'll see that the --unrestricted option is already there for all menu entries. This means that by default, all users are allowed to boot every menu option, even if you've set a superuser password:

menuentry 'CentOS Linux (3.10.0-693.11.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-693.el7.x86_64-advanced-f338b70d-ff57-404e-a349-6fd84ad1b692' {

So on CentOS, you don't have to do anything if you want all users to be able to use all available boot options.

Now, let's say that you have a menuentry that you want to be accessible to everybody. On CentOS, as I just pointed out, you don't have to do anything. On Ubuntu, add --unrestricted to the menuentry, as you did previously:

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-f0f002e8-16b2-45a1-bebc-41e518ab9497' --unrestricted {

If you want for nobody but the superuser to boot from a particular option, add --users "". (On CentOS, be sure to remove the --unrestricted option first.)

menuentry 'Ubuntu, with Linux 4.4.0-98-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.4.0-98-generic-recovery-f0f002e8-16b2-45a1-bebc-41e518ab9497' --users "" {

If you want for only the superuser and some other particular user to boot from a certain option, add --users, followed by the username. (Again, on CentOS, remove the --unrestricted option first.):

menuentry 'Ubuntu, with Linux 4.4.0-97-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.4.0-97-generic-advanced-f0f002e8-16b2-45a1-bebc-41e518ab9497' --users goldie {

If you have more than one user that you want to access a boot option, add an entry for the new user in the ### BEGIN /etc/grub.d/40_custom ### section. Then, add the new user to the menuentry that you want for him or her to access. Separate the usernames with a comma:

menuentry 'Ubuntu, with Linux 4.4.0-97-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.4.0-97-generic-advanced-f0f002e8-16b2-45a1-bebc-41e518ab9497' --users goldie,frank {

Save the file and reboot to try out the different options.

Now that we've gone through all this work, I need to remind you again that any manual edits that you've made to the grub.cfg file will be lost any time that a new grub.cfg gets generated. So, any time you do a system update that includes either installing or removing a kernel, you'll need to manually edit this file again to add back the password protection. (In fact, the only real reason I had you add the users and their passwords to the /etc/grub.d/40_custom file is so that you'll always have that information available to copy and paste into grub.cfg.) I wish that there were a more elegant way of doing this, but according to the official GRUB 2 documentation, there isn't.

Before we leave this topic, I'd like to share my personal thoughts about GRUB 2.

It was necessary to create a new version of GRUB because the old legacy version doesn't work with the new UEFI-based motherboards. However, there are things about GRUB 2 that are very disappointing. 

In the first place, unlike legacy GRUB, GRUB 2 isn't implemented consistently across all Linux distros. In fact, we've just seen in our demos how we have to do things differently when we go from CentOS to Ubuntu.

Next is the fact that the GRUB 2 developers gave us some good security options, but they haven't given us an elegant way of implementing them. I mean, really. The whole idea of telling us to implement security features by hand-editing a file that will get overwritten every time we do an operating system update just doesn't seem right.

And finally, there's the sad state of GRUB 2 documentation. I don't mean to sound like I'm tooting my own horn because I know that that's unbecoming. However, I think it's safe to say that this is the only comprehensive write-up you'll find anywhere for using the password-protection features of GRUB 2.