Bug 23406

Summary:	if install is cancelled after bootloader installed but before root password and user info entered, will boot to a system with "live" as user with no password and no root password
Product:	Mageia	Reporter:	Ben McMonagle <westel>
Component:	RPM Packages	Assignee:	Mageia tools maintainers <mageiatools>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	Normal	CC:	davidwhodgins, isobuild, mageia, marja11, tmb
Version:	Cauldron
Target Milestone:	Mageia 8
Hardware:	All
OS:	Linux
Whiteboard:	MGA6.1TOO
Source RPM:	draklive-install?	CVE:
Status comment:

Description Ben McMonagle 2018-08-07 22:43:04 CEST

Description of problem: see summary. this is a non-secure system. it would be better to install root password and user info  before installing the bootloader and rebooting the system. the other necessary things to setup during 1st boot like dkms wifi modules and online repos should still occur.


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


How reproducible: every time. 


Steps to Reproduce:
1.start live install from either desktop or boot menu install and reboot upon completion as indicated.
2.at the set root password and user info choose "cancel"
3.log in to installed system as user "live"
4.invoke terminal and change to root via "su -". no password is required.

Ben McMonagle 2018-08-07 22:59:10 CEST

Keywords: (none) => 6.1

Comment 1 Marja Van Waes 2018-08-09 22:26:48 CEST

I had never noticed the "cancel" button.

Does anyone know why it was added?

Assignee: bugsquad => mageiatools
Version: 6 => Cauldron
CC: (none) => isobuild, marja11
Whiteboard: (none) => MGA6.1TOO

Comment 2 Martin Whitaker 2018-08-11 00:04:55 CEST

(In reply to Marja Van Waes from comment #1)
> I had never noticed the "cancel" button.
> 
> Does anyone know why it was added?

The dialogue box is a shared component used for many purposes. Anything that uses that component gets the OK and Cancel buttons.

I've gone back and tested a few old ISOs.

Mageia 4 Live GNOME:
Clicking on cancel causes the machine to halt.
Rebooting takes you to the point where the DM is about to start, but then the machine just dies. But I can't get that ISO to boot to a working desktop in any way, so don't read too much into that.

Mageia 5 Live GNOME
Clicking on cancel causes the machine to reboot. But it then boots straight to the login screen and lets you login as "live" with no password.

Mageia 6 Live GNOME
As with the 6.1 ISOs, clicking on cancel takes you straight to the login screen.

So the behaviour has changed a bit, but it has always left you with an insecure system if you click on cancel.

CC: (none) => mageia

Comment 3 Thomas Backlund 2018-08-11 00:09:42 CEST

and its nothing that needs fixing for 6.1...

remember 6.1 is supposed to be a rollup of updates... its not a new release...

CC: (none) => tmb

Ben McMonagle 2018-11-13 00:42:45 CET

Target Milestone: --- => Mageia 7

Comment 4 Ben McMonagle 2020-06-04 02:56:51 CEST

valid for Mg8a cauldron alpha-1 .iso

Target Milestone: Mageia 7 => Mageia 8
Keywords: 6.1 => (none)

Comment 5 Dave Hodgins 2020-06-04 03:55:44 CEST

Is this really a bug? What would be a better result if the person installing
the system chooses to cancel setting the passwords?

CC: (none) => davidwhodgins

Comment 6 Ben McMonagle 2020-06-04 04:06:28 CEST

it was discovered as a result of video driver issue, and only the "cancel" button was  shown on this window, no text boxes, there was no way to proceed.

if a user attempts install on unsupported hardware, it is  possible that the end result - Live as user with  no p/w and no p/w root, will occur.

Comment 7 Ben McMonagle 2020-06-04 04:15:08 CEST

a better result would be a message advising that not setting  root and user name /password will result in running an insecure system, and  re-presenting the window.
Ideally if the user turns off the system or reboots, the uncompleted install would again  present the root/user password text boxes, rather than let insecure  system  run.

of course, if the user chooses to leave the boxes empty, and presses "ok/next" the system will then run,  again insecurely, but then it is explicitly at the users request.