Bug 19044

I can't reproduce that.

Is this an old cauldron, where you had to enter the root password to start MCC before, or is this a new cauldron?

If the latter: Which exact iso did you use to install Mageia?

Keywords: (none) => NEEDINFO
CC: (none) => marja11, thierry.vignaud

  Fresh install of recent* Classical 32-bit Mga6-RC on Samsung NC110 
netbook       (Real h/w; non-EFI, non-GPT, non-nVidia)

(* Downloaded 16/7 +  Cauldron update today)

This is per design

Status: NEW => RESOLVED
Resolution: (none) => INVALID

(In reply to Thierry Vignaud from comment #3)
> This is per design

So I don't need to try to reproduce it in a fresh 32bit traditional install?

Since when is this the design, and why?

Ah, maybe I understand... is this because of the fix for bug 17720?

So you don't get this if during install, you don't choose to add the user to the sudoers

> This is per design
  
   Uh?! 

> So you don't get this if during install, you don't choose to add the user to 
> the sudoers

I never put anyone in sudoers!

How can drakconf *not* accept Root password?

do you mind attaching /root/drakx/report.bug.xz from that install, Maurice?

I'd like to have a look at the "setRootPassword_addUser" step (it'll take a while before I can do an install, it won't be today).

Btw, now that you can start MCC as user:

Can you also run diskdrake as user?

If so:

Does that also work with a new user?

Created attachment 8254 [details]
/root/drakx/report.bug.xz w.r.t. MCC password

As  requested...

[Seems my posting last night didn't survive. Here it is again!]


> Can you also run diskdrake as user?

   User does not find diskdrake. Root does.

> Does that also work with a new user?

  Cannot login to 2nd user (2nd users' entry still marked 'Expired'...)

(In reply to Marja van Waes from comment #5)
> Ah, maybe I understand... is this because of the fix for bug 17720?

Sorry that was a wrong answer

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

(In reply to Maurice Batey from comment #9)
> Created attachment 8254 [details]
> /root/drakx/report.bug.xz w.r.t. MCC password
> 
> As  requested...

Thanks :-)

This looks odd to me, or doesn't this mean that the user is added to those groups:

 * running: usermod -G adm,ntools,ctools,rpm,wheel,xgrp mab with root /mnt

?

(In reply to Maurice Batey from comment #10)
> [Seems my posting last night didn't survive. Here it is again!]
> 
> 
> > Can you also run diskdrake as user?
> 
>    User does not find diskdrake. Root does.

That's good :-) So a user who starts MCC, cannot do any harm, or can the user still start it in MCC?
> 
> > Does that also work with a new user?
> 
>   Cannot login to 2nd user (2nd users' entry still marked 'Expired'...)

please remove /etc/shadow.lock and try again ;-)

Having done full Cauldron update on 64-bit Mga6-RC Plasma, I can confirm that:

If 1st user calls Drakconf (or Gparted, etc) and enters Root password, it is rejected, but if enters own password,  is accepted!

Now that the /etc/shadow.lock has been removed and can now operate 2nd user, 
I find that if the 2nd user calls e.g. Drakconf, the Root password is rejected, as is the 2nd user's password, BUT the 1st user's password is accepted!

I still need to try whether keeping an existing /home/first_user when installing helps to reproduce this bug (I didn't reproduce it in an entirely clean 32bit install)

Not that I understand why having an existing /home/first_user would auto-add that user to the wheel group etc. (which I think happened here)

Keywords: NEEDINFO => (none)
Summary: MCC requires *User* password; fails if Root password given! => MCC requires password of the first user; fails if Root (or non-first user) password given!

> Not that I understand why having an existing /home/first_user would auto-add 
> that user to the wheel group etc. (which I think happened here)

  That's what seems to have happened, because I never set 'wheel' for any user.

What I also didn't understand is how on earth the Root password could be *rejected*, but that appears to be what setting Wheel in a user's Groups will cause!  (Is that normal?)

Anyway, I have taken 1st user off Wheel, and the password situation has now reverted to normal.

Now the only puzzle is how did Wheel get set, so I guess the optimum thing to do is hold off for a while and see if it recurs anywhere.

Marja, Maurice, I don't think it's related to the group it belongs to. We have security settings in mcc that allow to choose which administration tools require a root user and which ones only require the current user's password. The question is why they got set this way.

Exactly, which security level did you give during installation?
and btw belonging to wheel group you should be able to do a lot of things....

CC: (none) => anaselli

> which security level did you give during installation?

I made no intentional change from the default.

I'm going to assume that Wheel got set accidentally, and was not an installation error, so propose this bug be closed, and hopefully will not need to be re-opened...

(In reply to Maurice Batey from comment #18)
> > which security level did you give during installation?
> 
> I made no intentional change from the default.
> 
> I'm going to assume that Wheel got set accidentally, and was not an
> installation error, so propose this bug be closed, and hopefully will not
> need to be re-opened...

but you hit this twice, didn't you?

On 2 occasions, yes, before I cancelled Wheel.

(In reply to Marja van Waes from comment #19)

> 
> but you hit this twice, didn't you?

(In reply to Maurice Batey from comment #20)
> On 2 occasions, yes, before I cancelled Wheel.

I think I meant in two clean installs, but re-reading the comments i don't see why I thought that.

No longer a problem here.

Closing.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED