Cannot set lock option in menu.lst without being overriden by update-grub

Confirmed, there is no option in update-grub that allows locking of the first boot option. Though I'm not sure why you want to completely disable booting without a password, which is what this is documented as doing? For instance, that means unattended reboots are no longer possible because of the need to enter a password.

Bug #21412 has been resolved now, so at least if you do set this option by hand it won't be silently overridden by upgrades; instead it'll be noisy and you'll still have to manage your kernel configs by hand... :-)

Thanks for confirming and also pointing out that the lock option won't be silently overridden by upgrades anymore. At this point it seems the bug title is no longer relevant. Rather it could be "Cannot set lock option without messy kernel upgrade procedure".

To clarify, I am making the case for a new option called lockdefault which will do for the default kernel what the other locks for other kernels.

My thoughts are that if you are going through all the trouble of looking out for the lock option, and then bailing out of a grub update because you don't want to override it, you might as well just support the lock option in the automagic default options so that kernel upgrades aren't problematic.

Another point is that the lock option is a grub _feature_ which people do use on their default kernel, regardless of breakage and inconveniences relating to debian's update-grub. It is debatable whether such people are misguided, but they will no doubt continue to use the lock option in this way under the impression that their system is more secure that way.

I accept that people who do this are not going to have unattended upgrades. However, I did not suggest that the distro is shipped with the lock option enabled by default and thereby break the unattended upgrades. Rather, this is a feature for those who do edit the menu.lst by hand.

> My thoughts are that if you are going through all the trouble of looking out for the lock option, and then
> bailing out of a grub update because you don't want to override it

That's not what we're doing. The update-grub code detects any manual changes to the "automagic kernel" list; it can't discern the meaning of any particular changes, it only reports that changes are present and asks whether they should be overwritten.

> Another point is that the lock option is a grub _feature_ which people do use on their default kernel,
> regardless of breakage and inconveniences relating to debian's update-grub. It is debatable whether
> such people are misguided, but they will no doubt continue to use the lock option in this way under the
> impression that their system is more secure that way.

Well, as I can't understand why anyone would want to use lock this way, I'm less likely to try to dedicate any time to supporting it properly with the present code.

@Steve

It seems you are saying you can't imagine any scenarios where someone would want to lock their default kernel. I don't think its that difficult, please try.

Here is just one. You work for a company where "official" policy dictates you may only use Windows workstations; any unauthorised software installation is forbidden.

Due to pressing business requirements, your boss gives you the go-ahead to install Ubuntu on a workstation as long as nobody finds out.

The last thing you need is for a technician to accidentally discover you have a Linux workstation on there - perhaps they were delivering some hardware update.

Having grub bork an "unauthorised" error is a good way to achieve that, there is plausible deniability.

Hi infodroid, Steve,

I'm using Debian Lenny and came across the same issue. My reason for wanting to lock the default boot option is simple: I'm using a Debian system as base for a firewall. I don't want some cracker installing an exploit, requiring a reboot to be activated. Better having no unattended upgrades than unattendedly being exploited :-) Of course not all exploits require a reboot for activation, but this limits at least a subset of them.

Btw: update-grub in Lenny still silently discards any manually added lock statement in the automagic kernel section.

Regards,

Jan Stap

outdated report & no more maintained distro; please send a new one if that issue still exist (using ubuntu-bug)