Plasma 5 reboot attempt takes me to login screen?

[user]

Thanks for explaining. Yes, I filed this bug report.

@wolfi323

Plasma5 does not have that “feature” because it is specific to kdm and kdm has been dropped.
There is a feature request for reimplementing it, but according to the developers it should be supported by systemd first to be able to do it properly.
(KDE4’s implementation is more or less a hack, that as mentioned only works with kdm)

So there is no sddm command line way for rebooting into another OS (grub entry), right?

Try to remove the >/dev/null from the kdmctl line, then you’d see a possible error message.

I did that. The result is:

Windows Boot Manager (on /dev/sdd1)
Rebooting in Windows
ok

and no reboot.

PS: you should probably run that script as user, not root.

That’s exactly what I am doing. I never even thought about running it as root as the whole idea is to be able to do it as user.

[wolfi323]

@heyjoe

Thanks for explaining. Yes, I filed this bug report.

I know, I marked it as duplicate.

So there is no sddm command line way for rebooting into another OS (grub entry), right?

Right.

Except grub2-once/grub2-reboot, followed by “systemctl reboot” or “halt -r”.

I did that. The result is:

Windows Boot Manager (on /dev/sdd1)
Rebooting in Windows
ok

and no reboot.

The script works fine.

From kdmctl’s docs: (which you linked to yourself)

shutdown (reboot|halt) =bootchoice] (ask|trynow|forcenow|schedule|start (*-1|end (force|forcemy|cancel)))*)

Request a system shutdown, either a reboot or a halt/poweroff.
An OS choice for the next boot may be specified from the list returned by listbootoptions

Shutdowns requested from per-display sockets are executed when the current session on that display exits.

So you need to logout after running the script (I already indicated how this could be done automatically). As soon as the KDE session closes, kdm should reboot your system and start Windows.

Works fine here on 13.2/KDE4 at least.

Btw, you probably don’t even need that whole script.
You can just as well run only kdmctl with the appropriate options if you prefer.

That’s exactly what I am doing. I never even thought about running it as root as the whole idea is to be able to do it as user.

But the ‘#’ command line prompt you posted suggests that you ran “su”/switched to root before.
If you didn’t, then sorry. I just wanted to mention it.

[wolfi323]

@wolfi323

Except grub2-once/grub2-reboot, followed by “systemctl reboot” or “halt -r”.

Of course you can also tell ksmserver to reboot (with qdbus) after setting the menu entry with grub2-once/grub2-reboot (which needs root permissions), which would cleanly close the Plasma session.
I already suggested that too.

The suggestion with kdmctl was mainly because you are using kdm now, and it would not require root privileges because kdm sets the entry to boot (it actually just calls grub2-reboot in fact, it can do that because it is running as root).

[user]

@wolfi323

I know, I marked it as duplicate.

You are everywhere

The script works fine.

Unfortunately it doesn’t do the job. I added a last line in it:

qdbus org.kde.ksmserver /KSMServer logout 0 1 0

and now it reboots. However it shows the GRUB menu and does not boot into Windows (as expected). So the only thing it does is a normal reboot.

@wolfi323

Of course you can also tell ksmserver to reboot (with qdbus) after setting the menu entry with grub2-once/grub2-reboot (which needs root permissions), which would cleanly close the Plasma session.
I already suggested that too.

The suggestion with kdmctl was mainly because you are using kdm now, and it would not require root privileges because kdm sets the entry to boot (it actually just calls grub2-reboot in fact, it can do that because it is running as root).

It seems even with kdm I can’t get what I want (or I am doing it wrong?)

Is there a way to use sddm and somehow grant a permission to the regular user to call grub2-once/grub2-reboot (e.g. through polkit)? What might be the security implications/dangers of that (if possible at all)?

[wolfi323]

@heyjoe

Unfortunately it doesn’t do the job. I added a last line in it:

qdbus org.kde.ksmserver /KSMServer logout 0 1 0

and now it reboots. However it shows the GRUB menu and does not boot into Windows (as expected). So the only thing it does is a normal reboot.

That line tells Plasma/ksmserver to reboot.
Try a logout instead:

qdbus org.kde.ksmserver /KSMServer logout 0 0 0

The explicit reboot request might override what you set with kdmctl before.

Logout may sound counter-intuitive, but it makes sense: you already told kdm to reboot (to Windows) after the current session ends, i.e. after the user logs out.

Is there a way to use sddm and somehow grant a permission to the regular user to call grub2-once/grub2-reboot (e.g. through polkit)? What might be the security implications/dangers of that (if possible at all)?

As I wrote, you could use sudo, and allow the regular user to run this command without password via /etc/sudoers.
Or you could use pkexec, which uses polkit instead to achieve basically the same.

The implications are that all users can then set a boot entry for the next boot.
You could restrict it to certain users though.

OTOH, with kdm/kdmctl this is already possible as well, every logged in user can use it.

[user]

@wolfi323

That line tells Plasma/ksmserver to reboot.
Try a logout instead:

qdbus org.kde.ksmserver /KSMServer logout 0 0 0

The explicit reboot request might override what you set with kdmctl before.

Logout may sound counter-intuitive, but it makes sense: you already told kdm to reboot (to Windows) after the current session ends, i.e. after the user logs out.

That worked! Thanks!

As I wrote, you could use sudo, and allow the regular user to run this command without password via /etc/sudoers.

I digged a little into that too. The man page of sudoers is like a second university education

Using visudo I tried to restrict username ‘heyjoe’ to be able to run grub2-once.

This works:

heyjoe ALL=(root) NOPASSWD: /usr/sbin/grub2-once

After that I can run ‘sudo grub2-once’ without password but I can’t run directly grub2-once (is that normal?)

But this doesn’t work (I was willing to restrict only to localhost):

Host_Alias    LOCALHOST = localhost # tried 127.0.0.1 - same lack of luck
heyjoe LOCALHOST=(root) NOPASSWD: /usr/sbin/grub2-once

What am I doing wrong?

Or you could use pkexec, which uses polkit instead to achieve basically the same.

What should I put in /etc/polkit-default-privs.local to allow a particular user (heyjoe) to be able to run grub2-once?

OTOH, with kdm/kdmctl this is already possible as well, every logged in user can use it.

Thanks for explaining. I suppose from long term perspective it would be wiser to use sddm as you mentioned in the bug report that kdm is no longer developed. So I am looking how to do it with one of the other 2 methods without making anything dangerous for the system.

[wolfi323]

@heyjoe

That worked! Thanks!

Great!
I only tested it with KDE4 so far, but I could reproduce the reboot “problem” so was pretty sure that’s it…

After that I can run ‘sudo grub2-once’ without password but I can’t run directly grub2-once (is that normal?)

Yes, that is normal.
Configuring sudo to allow running a program without root password doesn’t tell the shell that it should use sudo to run that command.

You could create an alias (alias grub2-once=“sudo grub2-once”) if you want that.
Or create a script that calls “sudo grub2-once”, name it grub2-once and put it in a place where it overrides /usr/bin/. (this could be /usr/local/bin/ or ~/bin/, or anything else you set in your $PATH before /usr/bin/)

Another option that I didn’t think of before would be to set the “suid root” bit via chmod.
This will be overwritten by updates though, so you should add a corresponding line to /etc/permissions.local.
Of course, then everybody will be able to run that command as root then, or to be explicit, whoever runs the command it will run as root.

Host_Alias LOCALHOST = localhost # tried 127.0.0.1 - same lack of luck
heyjoe LOCALHOST=(root) NOPASSWD: /usr/sbin/grub2-once

What am I doing wrong?

No idea currently.
I would have to look that up myself.

What should I put in /etc/polkit-default-privs.local to allow a particular user (heyjoe) to be able to run grub2-once?

That’s not possible that way.
/etc/polkit-default-privs.local is just an (open)SUSE simplification to override the (open)SUSE specific privilege settings in /etc/polkit-default-privs.standard or /etc/polkit-default-privs.restrictive (depending on your security settings).

polkit itself only takes its rules from javascript scriptlets in /etc/polkit-1/rules.d/.
“polkit_set_default_privs” creates those scriptlets from (open)SUSE’s files.

To create rules for pkexec, you need to create a scriptlet in /etc/polkit-1/rules.d/ yourself.
I explained how to do that for launching YaST without root password here in the forums a while ago.
But here as well, I would have to look it up myself again.

I will do so tomorrow, now it’s time for bed for me…

Thanks for explaining. I suppose from long term perspective it would be wiser to use sddm as you mentioned in the bug report that kdm is no longer developed. So I am looking how to do it with one of the other 2 methods without making anything dangerous for the system.

kdm will definitely remain as long as we have KDE4 applications, because other parts of kde4-workspace are needed as well.

Yes, it is not actively maintained any more, but should continue to work as long as we have Qt4 and Xorg, which won’t be dropped any time soon.
And as far as the latter is concerned, sddm currently only works on Xorg too (Wayland support is work in progress). Though it does support starting Wayland sessions, which kdm doesn’t.

Actually, sddm does lack many features that kdm has (the ‘s’ stands for “simple”), yet another reason why we keep kdm around.

So, as long as you don’t want/need anything that kdm doesn’t support (like starting Wayland sessions), I wouldn’t worry, for a few more years at least.

[user]

Thank you so much for being so detailed! I always learn new things when you reply to threads. E.g. I just learned there is such thing as Wayland. I guess I will need to find more info about it although perhaps I may stay with kdm as you explaiend.

I know it is not much on topic but I wonder: what is the reason to have separate security management systems such as sudoers and polkit? Can’t one thing do the job? It reminds me of hosts.allow/deny which I still don’t understand why it might be needed when there is a firewall. Maybe you could recommend a reading about all these things?

[wolfi323]

Sorry for the delayed response, I was quite busy the last days…

@heyjoe

E.g. I just learned there is such thing as Wayland. I guess I will need to find more info about it although perhaps I may stay with kdm as you explaiend.

Wayland is meant to be a “successor” to X11 and address some of its shortcomings (especially regarding security).

But note that Wayland support in Plasma5 is still unfinished and very much work in progress.
And the Wayland in Leap 42.1 is quite old, Plasma5 will not even start with that version, so it is built without Wayland support anyway.

Even GNOME is not using Wayland in Leap 42.1 AFAIK, though they switched to using Wayland by default in Tumbleweed a while ago already.
(Plasma5 can also run in Wayland in Tumbleweed, but there are still problems and things are missing)

IMHO, it will still be quite a while until Wayland will really replace Xorg in general, and I doubt that Xorg will disappear at all.

I think the best way to try it out currently is using an openSUSE Krypton LiveCD…

I know it is not much on topic but I wonder: what is the reason to have separate security management systems such as sudoers and polkit?

That’s historical.
sudo exists since decades (according to sudo - Wikipedia since about 1980).

polkit was created to address its shortcomings, in particular related to standard desktop usage (e.g. sudo is a command line tool, it cannot be easily integrated into the desktop, and can also only be used to run complete programs as root, and so on).

Anyway, here’s how you could configure pkexec to allow running a certain command as root:
https://forums.opensuse.org/showthread.php/505762-run-yast-without-entering-root-password-sudoers-help?p=2701795#post2701795
In short, create a file /usr/share/polkit-1/actions/org.opensuse.pkexec.yast2.policy with a content like this:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
<policyconfig>

  <action id="org.opensuse.pkexec.yast2">
    <message>Authentication is required to run YaST2</message>
    <icon_name>yast2</icon_name>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/yast2</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
  </action>

</policyconfig>

To do the same with other commands, replace yast2 (and /usr/sbin/yast2) accordingly, the line true is only needed for GUI applications, and can be omitted for command line tools.
(and I suppose you don’t have to specify an icon either… )
You should then be able to run YaST as root without a password via:

pkexec yast2

Regarding priviledges, the important part are the three lines with <allow_active>, <allow_inactive>, and <allow_any>.
They specify what user(s) may run it as root with which password (the user’s, root’s, or none).
“yes” means no password is needed, auth_admin means the user needs to enter the root password (there’s also auth_admin_kepp which will remember the password for some time so you don’t have to enter it every time), and there’s also auth_self/auth_self_keep which will request the user’s password, and “no” which disallows the action completely.

By default, polkit knows about three different user types:

• “active” ones that are locally logged in and in an active session, e.g. a normal desktop user
• “inactive” ones that are locally logged in but in an inactive session, e.g. a different user currently logged in but not you that’s actively using the desktop
• “any”, everybody, also remote users

If your satisfied with this, you don’t need the javascript sniplets in /etc/polkit-1/rules.d/ I mentioned.
With such javascript scriptlets you are more flexible though, you can e.g. verify the exact user name or group.

More informations are available in “man polkit” and e.g. here: polkit - ArchWiki (and of course the official documentation at polkit Reference Manual: polkit Reference Manual, but that’s probably overkill…).
See also Polkit - Wikipedia for a more general description of polkit.

As I mentioned already, openSUSE has some simplification to override the default polkit rules via /etc/polkit-default-privs.{local|standard|restrictive}, those get “translated” into javascript code by running “polkit_set_default_privs”.

[user]

Thanks wolfi!