Description of problem: I install Mageia 1 RC and during Summary I make sure that there is no flag in the field "Allow users to manage the connection". Same with draknetcenter embedded in MCC after install is complete. In both cases the user can simply click on the connection icon and manage the connection(s) as superuser. This is unexpected, potentially a security risk (depending on who is the user) and makes the field "allow users..." without any real value. What I would expect to see: if I don't flag the "Allow users..." I would imagine that the user could either not manage the connection(s) at all, or only after entering the root password.
I confirm this. I've noticed it for a long time, well back into the Mandriva days, and I just assumed that it was intended to work that way, but Dick is correct.
CC: (none) => ftg
There're two different configurations here: - "Allow users to manage the connection" means allow users to connect/disconnect that network interface - "Configure Network" option means "start drakconnet", which can be used to configure a new network interface; this option is managed by the setting in the "Network" section in draksec (aka drakconf -> security -> configure authentication for Mageia tools) I've just tested and both options work as expected. Maybe the "Allow users to manage the connection" string should be clearer e.g.: Allow users to manage (connect/disconnect) the connection but that will have to wait for Mageia2, too late to change strings in Mageia1, IINM.
Component: Installer => RPM Packages
Yes you can connect/disconnect, but I also see a button "configure" which enables the user to change various settings. So I don't understand what is wrong with the string... But it can wait till after 1 final, sure.
The scenario I referred to is when you *don't* enable "allow users to manage the connection". I never do, yet I can click on the network icon in the panel, and connect/disconnect it from a normal userid. The "configure" button from the opened network applet works as well.
"Allow users to manage the connection" enabled: - Right click the net_applet icon -> Disconnect wired Ethernet (eth1) -> eth1 is disconnected - Right click the net_applet icon -> Connect wired Ethernet (eth1) -> eth1 is connected "Allow users to manage the connection" disabled: - Right click the net_applet icon -> Disconnect wired Ethernet (eth1) -> a consolehelper window appears asking for the root password - Right click the net_applet icon -> Connect wired Ethernet (eth1) -> a consolehelper window appears asking for the root password Right clicking "Configure Network": - with draksec -> Network -> Network Configuration set to "Root Password" a consolehelper appears asking for the root password - with draksec -> Network -> Network Configuration set to "User Password" a consolehelper appears asking for the user password - with draksec -> Network -> Network Configuration set to "No Password" drakconnect opens directly These are the results of my tests.
As per comment #4: indeed, I can configure always, without being asked for the root password.
> These are the results of my tests. You are correct, but your test case is not ours. Left-click on the network applet icon to open the full-function window, and you'll find that connect/disconnect and configure work without authentication.
You could have said "left-clicking" from the start... Left-clicking opens draknetcenter, controlled by draksec -> Network -> Network Center. The default setting is "no password".
CC: (none) => thierry.vignaudAssignee: bugsquad => mageia
??? From comment #1: >In both cases the user can simply click on the connection icon and manage the >connection(s) as superuser. "Click" in my experience has always meant mouse button one, making "left-click" the default. It is "right click" that needs to be explicitly qualified.
Maybe, but I rarely left click the applet, usually right click, so different use cases, i.e. "click" translated to "right click" in my mind. Anyway, all is sorted out now (and the bug is assigned to blino, who AFAIK worked on drakx-net the most around here, IIUC).
@ Olivier Any news?
CC: (none) => marja11
Summary: Disallow user to manage connection: he still can => Disallow user to manage connection: he still can with network applet
Pinging. because nothing happened to this report since more than 3 months ago, and it still has the status NEW or REOPENED. @ Oliver Please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead. Don't change anything if you want to be pinged by me here again :)
3 monthly ping @ Dick I didn't check with rc, is this bug still valid?
Marja: Sorry didn't really pay much attention to this with the rc's. I will try and see how it is during the coming weekend.
The bug is still valid, IMHO
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Applies to 2 and Cauldron
Keywords: NEEDINFO => (none)CC: (none) => sander.lepikWhiteboard: (none) => MGA2TOO
Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D
Sorry, but this bug saw no action since more than 2 yrs ago. No cauldron package has stayed the same since then. Closing as OLD Please reopen if this report is still valid for _current_ cauldron and/or fully updated Mageia 4
Status: NEW => RESOLVEDResolution: (none) => OLD
Closed without having been fixed. It is still valid !
Keywords: (none) => 6dev1Status: RESOLVED => REOPENEDResolution: OLD => (none)Source RPM: drakx-net-0.97.1.mga1 => drakx-net-2.23-2.mga6Whiteboard: MGA2TOO => (none)
Valid for current 6sta1 isos
Keywords: 6dev1 => 6sta1Source RPM: drakx-net-2.23-2.mga6 => drakx-net-2.25-1.mga6
Valid for 5.1 iso as well
Summary: Disallow user to manage connection: he still can with network applet => [5.1] Disallow user to manage connection: he still can with network appletSource RPM: drakx-net-2.25-1.mga6 => drakx-net-2.27-1.mga6
Summary: [5.1] Disallow user to manage connection: he still can with network applet => Disallow user to manage connection: he still can with network appletWhiteboard: (none) => MGA5TOO
Assignee: mageia => mageiatools
Pinging. because nothing happened to this report since more than 3 months ago, and it still has the status NEW or REOPENED, is valid in MGA6 Maintainer, Please feedback about the progress of this fix
CC: (none) => neoser10