It's working as expected here .
Using kdm as the dm manager, settings reboot/shutdown restricted to the root user only (using systemsettings), log out /log from your session to get a reload of kdm configuration and it's working as expect :
You get a popup for root password from the « kdm » screen to reboot/shutdown your computer.

@John Balcaen...

Well, I'm not using KDM - I manually issue "startx" - and the problem I'm seeing is not in KDM either way, but in the KDE shutdown dialog.  Press Ctrl+Alt+Del or click on "leave", then choose "reboot" from the menu.  It'll reboot, no questions or passwords asked.  Same thing for shutting down.

So how did you configure pam to prevent the login/logout functionnality ?
I guess you did try on  lxde/xfce/gnome and you're not able to reproduce on thoses DE?

I'm forgot to say that i'm not able to reproduce the reboot/halt functionality with kde when using startx if the reboot has been forbidden via msec.
( ALLOW_REBOOT set to no )
The KDE Session simply logout but the computer does not halt or reboot & the user end up in a tty session.

If the problem is ending in a tty session & not beeing asked the root password then you should open a bug report against kde to ask them how to « deal » with that behaviour (but i think the answer is going to be please use kdm which provides thoses functionnality)

No, it does not end in a tty session; it simply reboots the system.  (And btw, I am aware of the fact that the upstream KDE developers would rather have me use KDM, because using "startx" is so un-Windowslike. :p)

As to your first question, I disabled shutdown, reboot and suspend/hibernate by editing the pertaining PAM files - which I had also done on my PCLinuxOS (with KDE 3.5.10) and which worked there.  In addition to that, I have also disallowed the above via the msec GUI in the Mageia Control Center.

An example of "/etc/pam.d/halt" and "/etc/pam.d/reboot" follows...

<snippet>

auth       requisite    pam_rootok.so
auth       required     pam_console.so
#auth       include     system-auth
account    required     pam_permit.so

</snippet>

but i guess you still have a /usr/bin/reboot as a symlink to consolehelper ?

(thoses halt/reboot pam config files are the default by the way on mageia.)

Uhm, no, they were not the default.  The first line had "sufficient" instead of "requisite".  

And no...

<snippet>

[13:32:00][localhost:/home/aragorn]
[0][aragorn][$] > ll /usr/bin/reboot
ls: cannot access /usr/bin/reboot: No such file or directory

[15:26:58][localhost:/home/aragorn]
[0][aragorn][$] > ll /usr/bin/halt
ls: cannot access /usr/bin/halt: No such file or directory

</snippet>

Those two files - which normally are indeed symbolic links to consolehelper - have never been installed here.  I know that for a fact because that's one of the first things I look for with every installation of a new distribution, or a new release of a distribution.

On the one hand, I am wondering whether creating those symlinks would change the behavior as I've reported it.  I did find it either way strange that those symlinks did not get to be installed by default [*], and so I was under the assumption that Mageia 1 used a different privilege granting method than policykit.

On the other hand, the executables set in KDE's System Settings - with regard to KDM, of course - were not pointing at those, but at "/sbin/halt" and "/sbin/reboot", so it's possible that KDE tries to invoke those when offering the shutdown options to the user from within the user's KDE session.  And in this lies another curiosity, because KDE does not run with root privileges (although the X server does), so KDE obviously has some way of gaining root privileges through the X server (or through dbus) outside of my control.


[*] One could put the blame on an isolated case of an installation that somehow
    went bizarrely wrong for whatever reason, but I have already had to reinstall
    Mageia quite a few times.  The first two times was because I had not created
    "/usr" large enough.  The last time was because the hard disk and motherboard
    of this machine had both been replaced after a hard disk crash.  (The mother-
    board also had issues.)

Hum indeed i did not notice your change on pam_rootok & switching to requisite instead of sufficient cause the same behaviour as you: aka kde started from tty1 via a startx is.

Coling > since you're more used with pam then me, do you have an idea here ? :)

CC: (none) => mageia

@ Aragorn

Is this problem still there?

This bug was filed against Mageia 1, and bug 3316 against cauldron, so you filed them for two different systems (or at least two different installs), correct?

Keywords: (none) => NEEDINFO
CC: (none) => marja11

My apologies.  All bugs I have filed are against Mageia 1, not against Cauldron.  There was some confusion on my end at the time of filing the bugs because the browser window was not correctly updating and parts of the screen were invisible after scrolling.  Bug #3316 is a Mageia 1 bug, not a Cauldron bug.

For the record, I have only ONE Mageia installation, i.e. Mageia 1 Official.  I currently neither have the time nor the resources for beta testing a pre-release distribution.

Aragorn:

can you show me the output of "urpmq --list-url"?

i am having these problems only on cauldron, so i suspect you have perhaps updated accidentally to cauldron at some point...

CC: (none) => alien

I do not have the repos for Cauldron selected, but here's the output nevertheless...


[03:33:42][localhost:/home/aragorn]
[0][aragorn][$] > sudo urpmq --list-url
[sudo] password for root:
Mageia - 1 - x86_64 DVD cdrom://x86_64/media/core
Core Release http://ftp.belnet.be/mirror/mageia/distrib/1/x86_64/media/core/release
Core Release Debug
Core Updates http://ftp.belnet.be/mirror/mageia/distrib/1/x86_64/media/core/updates
Core Updates Debug
Core Updates Testing
Core Updates Testing Debug
Core Backports http://ftp.belnet.be/mirror/mageia/distrib/1/x86_64/media/core/backports
Core Backports Debug
Core Backports Testing
Core Backports Testing Debug
Nonfree Release http://ftp.belnet.be/mirror/mageia/distrib/1/x86_64/media/nonfree/release
Nonfree Release Debug
Nonfree Updates http://ftp.belnet.be/mirror/mageia/distrib/1/x86_64/media/nonfree/updates
Nonfree Updates Debug
Nonfree Updates Testing
Nonfree Updates Testing Debug
Nonfree Backports http://ftp.belnet.be/mirror/mageia/distrib/1/x86_64/media/nonfree/backports
Nonfree Backports Debug
Nonfree Backports Testing
Nonfree Backports Testing Debug
Tainted Release
Tainted Release Debug
Tainted Updates
Tainted Updates Debug
Tainted Updates Testing
Tainted Updates Testing Debug
Tainted Backports
Tainted Backports Debug
Tainted Backports Testing
Tainted Backports Testing Debug
Core 32bit Release http://ftp.belnet.be/mirror/mageia/distrib/1/i586/media/core/release
Core 32bit Release Debug
Core 32bit Updates http://ftp.belnet.be/mirror/mageia/distrib/1/i586/media/core/updates
Core 32bit Updates Debug
Core 32bit Updates Testing
Core 32bit Updates Testing Debug
Core 32bit Backports
Core 32bit Backports Debug
Core 32bit Backports Testing
Core 32bit Backports Testing Debug

hmmm, i'm a bit puzzled about this, really... maybe because of backports?

Nope.  It was that way from the start, i.e. the first time I installed Mageia 1 on this system, which was at around May or June of last year.  I had to reinstall Mageia 1 a few times in the meantime, among other reasons because my hard disk broke down (while still under warranty) and I had to have it replaced.

Now, II'm not a developer - I don't speak C :p - but I do know enough about UNIX to know that this is most likely a matter of either some SUID root exexutable somewhere, or else it's an escalation of privileges via dbus/hald and friends.

As with all four of the bugs I've filed so far - at least, if I recall correctly, because it's been some time again - I strongly suspect that most of these problems are KDE-related.  The PAM/msec stuff does work correctly on account of a character mode console.  You can't even reboot the system by pressing Ctrl+Alt+Del anymore in a character mode console when you deny reboot to unprivileged users via msec, but once you're in KDE, it's like everything is possible, and without a dialog asking you to authenticate with the root password.

So far I haven't had a chance to try out openSUSE 12.1 yet, but according to the people in alt.os.linux.suse, the KDE implementation in openSUSE behaves as it should and honors PAM and other security settings.  I could be wrong, but I think that the quirks of the KDE implementation in Mageia might have been carried over from Mandriva.  Mandriva/Mandrake has always made liberal use of SUID root executables, and it's probably related to that.

(In reply to comment #10)
> Hum indeed i did not notice your change on pam_rootok & switching to requisite
> instead of sufficient cause the same behaviour as you: aka kde started from
> tty1 via a startx is.

As said here i can reproduce your issue here onfly if i'm changing the default mageia configuration to the one you did.
Without thoses changes kde does not reboot when started from tty.

(In reply to comment #17)
[...]
> 
> So far I haven't had a chance to try out openSUSE 12.1 yet, but according to
> the people in alt.os.linux.suse, the KDE implementation in openSUSE behaves as
> it should and honors PAM and other security settings.  I could be wrong, but I
> think that the quirks of the KDE implementation in Mageia might have been
> carried over from Mandriva.  Mandriva/Mandrake has always made liberal use of
> SUID root executables, and it's probably related to that.
There's no patch regarding pam in our kde's package & i would be pleased to see where we whave suid root executables in mageia where we should not to fix it (in kde especially).

Hum i tried on my mageia 1 x86_64 box & in fact i'm not able to reproduce at all while it seems that i was able on i586.
starting kde from startx (with just a ~/.xinitrc with exec startkde) does not allow me to reboot/halt from the kde menu
halt/reboot pam files are setup like in comment #5

Is there something i'm missing eventually (this bug report is quite long now :p )

Are you still able to reproduce ?

I haven't really checked lately whether I can still reproduce the bug, as I prefer to keep my system security settings as they are now.  I have disabled the shutdown/reboot choice in the menu for my own user account so that it only offers me the logout (from KDE) option, which returns me to a Bash prompt.

For what it's worth, I don't have an .xinitrc file, and the kernel I'm running is the "server" flavor, because that's what Mageia installed.

(In reply to comment #14)

> 
> i am having these problems only on cauldron, so i suspect you have perhaps
> updated accidentally to cauldron at some point...

@ AL13N

I understand you have the "KDE overrides security settings issue", too, albeit in cauldron, or do I misunderstand?

(I should go look now, whether you reported that against cauldron, but I'm too lazy, you'll tell me ;) )

(In reply to comment #20)
> For what it's worth, I don't have an .xinitrc file, and the kernel I'm running
> is the "server" flavor, because that's what Mageia installed.
hum.
How do you launch kde then ?
(to use startx here i'm just adding a exec startkde in ~/.xinitrc ).
The kernel should not have any impact (& it's strange that you've got the -server flavour installed).

@John: I start KDE by just typing "startx" at the command prompt.  However, there is no .xinitrc.  If I want to start another desktop environment than KDE, I supply it as a commandline parameter to "startx".

As for the server kernel, that is strange indeed, but this too is a Mandriva legacy.  As a regular on alt.os.linux.mandriva, I have seen many people talk about how Mandriva installed a server kernel on a desktop system.  I'm not even sure what the differences are between the server flavor and the desktop flavor as I haven't looked at the .config files, but I suspect that the kernel interrupt timer frequency settings might be "snappier" for the desktop flavor kernel, and that the server flavor kernel may not have (full) kernel preemption enabled.

For what it's worth, the hardware of this machine is:
- ASrock N68-S3 motherboard
- AMD Athlon X2 3.0 GHz processor chip
- 4 GB DDR3 RAM
- 1 SATA hard disk (with Mageia 1)
- 1 PATA hard disk (from an older machine - has PCLinuxOS on it)
- 1 SATA DVD writer (LiteOn)
- 1 cardreader (unused)
- PCIe video adapter card (Asus EN (GeForce) 210)  

(There is an onboard nVidia adapter but I'm not using that as it uses shared memory.)

(In reply to comment #21)
> (In reply to comment #14)
> 
> > 
> > i am having these problems only on cauldron, so i suspect you have perhaps
> > updated accidentally to cauldron at some point...
> 
> @ AL13N
> 
> I understand you have the "KDE overrides security settings issue", too, albeit
> in cauldron, or do I misunderstand?
> 
> (I should go look now, whether you reported that against cauldron, but I'm too
> lazy, you'll tell me ;) )

arrgh, i'm going nuts...

all the questions i posed were for bug #3316 /o\

Well, I've got good news on account of this bug.  It would seem that one of the updates fixed it, because I have tried with another user account with the same privileges - i.e. member of the wheel group - and a new KDE session, set up with all the defaults.  These defaults do still allow the user to choose "shutdown" and "reboot" from the logout menu, but selecting either of those has no effect.  It simply logs you out.

In other words, if there isn't anyone else out there with this problem, then as far as I'm concerned you may consider this one closed.  Works as desired now, so... ;-)

(In reply to comment #25)

> 
> In other words, if there isn't anyone else out there with this problem, then as
> far as I'm concerned you may consider this one closed.  Works as desired now,
> so... ;-)

@ Aragorn,

Thanks for your feedback on your bugs :)

@ mikala

you reproduced this bug on i586, did it get fixed there, too?

Hardware: x86_64 => All

(In reply to comment #26)
> (In reply to comment #25)
> 
> > 
> > In other words, if there isn't anyone else out there with this problem, then as
> > far as I'm concerned you may consider this one closed.  Works as desired now,
> > so... ;-)
> 

> 
> @ mikala
> 
> you reproduced this bug on i586, did it get fixed there, too?

No reply, I assume it got fixed
Feel free to reopen when I'm wrong

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