Solved Missing power buttons when logged in from SDDM

bsduck

bsduck

Hello,

I usually start KDE Plasma with startx:
~/.xinitrc
Code: 
[...]

exec ck-launch-session startplasma-x11

I decided to give SDDM a try, but noticed that when I log in from SDDM, the power buttons (shutdown, reboot, suspend) normally present in the main menu of the desktop environment as well as in the logout dialog, are missing. When Plasma is started from the command line, they are present and working as expected.

Whether I select the default "Plasma (X11)" session or the "User Session" (which reads the user's .xinitrc) doesn't make a difference.

Meanwhile, power buttons are present and working on the SDDM login screen itself.

Therefore my question to SDDM users: is there something in particular you need to configure to get the power buttons in Plasma? Or do you just don't have them but don't care?
 
All I know is that a) it definitely works as intended here*) and b) console-kit stuff is "kind of" complicated 🙈 (although I don't really think the systemd-based alternative would be any better ....)

What happens if you move your .xinitrc out of the way? Just asking because the Plasma-session configured in sddm should already handle launching a ck session.....

*) ah wait, I remember I had some issue with consolekit and sddm in the past and back then, I "solved" it in a very dirty way:
Code: 
$ cat /etc/rc.conf.d/sddm 
killall console-kit-daemon >/dev/null 2>&1
 
zirias@ said:
What happens if you move your .xinitrc out of the way?
Click to expand...
No difference.

I tried as you suggested to create the executable file /etc/rc.conf.d/sddm with the content killall console-kit-daemon >/dev/null 2>&1 but that doesn't make a difference either...
 
It looks like you've been using KDE for a while. So you have dbus up and your user is included in operator group?
Apparently, the inherited credentials and permissions are different whether you run X as your user or from a display manager, as root.
 
Ok sorry, that's all I had here (and this very dirty "just kill the daemon" was only ever necessary on one machine, others worked fine without it) – I have to admit I really don't understand how exactly consolekit works :(
Let's hope someone on here knows better than me.
 
bsduck said:
Hello,

I usually start KDE Plasma with startx:
~/.xinitrc
Code: 
[...]

exec ck-launch-session startplasma-x11

I decided to give SDDM a try, but noticed that when I log in from SDDM, the power buttons (shutdown, reboot, suspend) normally present in the main menu of the desktop environment as well as in the logout dialog, are missing. When Plasma is started from the command line, they are present and working as expected.

Whether I select the default "Plasma (X11)" session or the "User Session" (which reads the user's .xinitrc) doesn't make a difference.

Meanwhile, power buttons are present and working on the SDDM login screen itself.

Therefore my question to SDDM users: is there something in particular you need to configure to get the power buttons in Plasma? Or do you just don't have them but don't care?
Click to expand...
Just checked my laptop - power buttons are present in SDDM (but don't work), and are absent in the logout menu in KDE Plasma... So to shut down, I have to su root, and issue the command in Konsole... it's a bit of a fuss, but I'm happy to have FreeBSD at all on bare metal on a Lenovo Ideapad 720S 13ARR...

On my VMs (on a ROG Zephyrus laptop), power buttons don't work on SDDM, but do work on the logout menu. I didn't do anything special, but I suspect that FreeBSD's ACPI API has to like your hardware.
 
astyle said:
I didn't do anything special, but I suspect that FreeBSD's ACPI API has to like your hardware.
Click to expand...
I'm pretty sure these issues are related to consolekit/polkit.

The problem they are trying to solve is to allow some administrative tasks (like shutdown) to a normal user, but only when this normal user is logged into a local (X) session. Unfortunately, I don't know how it works internally, so can't help troubleshooting here :(
 
zirias@ said:
I'm pretty sure these issues are related to consolekit/polkit.

The problem they are trying to solve is to allow some administrative tasks (like shutdown) to a normal user, but only when this normal user is logged into a local (X) session. Unfortunately, I don't know how it works internally, so can't help troubleshooting here :(
Click to expand...
Try this:
If you installed sddm by binary package you have to set this rule in order to get this module functional:

Create this file /usr/local/etc/polkit-1/rules-d/40-wheel-group.rules with this content:

polkit.addRule(function(action, subject) {
if (subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
Click to expand...

FreeBSD/Setup - KDE Community Wiki

community.kde.org community.kde.org

I don't need the above. I just added my user to video, wheel, operator.
 
I do not have this issue. Buttons are there and they work. On my desktop, laptop and VM.
I have done nothing at installation time. All good out of the box.
 
zirias@ said:
This however looks to me like another workaround, it just allows the actions for anyone in a group, independent of the local session. Might be worth a shot, but it's not how it's intended to work.
Click to expand...
Sure?
Run startx to "own" X, instead sddm runs the greeter under a system user. You will need extra permissions if you want to perform certain actions like shutting down the machine for other regular users.
My understanding is limited.

Dbus and video wheel operator groups made the difference for me
 
Last edited:
Pretty sure, these functions should be available to a user logged in to a local session, independent of any group memberships.

I just remembered one thing to check when this doesn't work, have a look at your consolekit session:
Code: 
$ ck-list-sessions
Session2:
        unix-user = '10000'
        realname = 'Felix Palmen'
        seat = 'Seat1'
        session-type = 'unspecified'
        session-class = 'user'
        session-state = 'active'
        active = TRUE
        x11-display = ':0'
        x11-display-device = '/dev/ttyv8'
        display-device = '/dev/   ?   '
        remote-host-name = ''
        is-local = TRUE
        on-since = '2023-03-01T18:43:42.644936Z'
        login-session-id = ''
        XDG_RUNTIME_DIR = '/var/run/user/10000'
        VTNr = '9'

Here, the session must be active and is-local must be TRUE, otherwise these buttons won't work/appear. Also, if you see more than one active session for your user, you will run into issues as well.

edit you can also try to issue a shutdown or reboot command from the terminal to see what happens:
Code: 
[shutdown]
dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop
[reboot]
dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart
 
CuatroTorres said:
Dbus and video wheel operator groups made the difference for me
Click to expand...
I put myself into those groups every time I do a fresh install of FreeBSD, but it's still a tossup on whether the power buttons work on SDDM or the logout menu. I do enable dbus, as well. I personally can live with this, though.
 
zirias@ said:
Here, the session must be active and is-local must be TRUE, otherwise these buttons won't work/appear.
Click to expand...
You nailed it:
ck-list-sessions
Code: 
Session2:
        unix-user = '1001'
        realname = 'bsduck'
        seat = 'Seat3'
        session-type = 'unspecified'
        session-class = 'user'
        session-state = 'online'
        active = FALSE
        x11-display = ':0'
        x11-display-device = ''
        display-device = '/dev/   ?   '
        remote-host-name = ''
        is-local = TRUE
        on-since = '2023-03-07T19:19:42.233492Z'
        login-session-id = ''
        XDG_RUNTIME_DIR = '/var/run/user/1001'
How can I make the session active?
 
If only I knew. All I know is: here's the problem. But consolekit really is kind of "black magic" to me, sorry :(
 
bsduck said:
How can I make the session active?
Click to expand...
I normally don't need to make use of a second ConsoleKit session unless something is up on the first one, like a broken lockscreen or a borked Wayland session. But last time I needed to kill the crashed lockscreen, the workaround was to log in on another TTY, and use root powers to restart the Xorg session (kill the process). I think that restarting Xorg on the original TTY makes the session active again - but I never really verified that, it's just an educated guess and some old notes from me.
 
I finally got it: the troublemaker is the sysctl security.bsd.see_other_uids being set to 0. I didn't find out what process exactly (run as root, sddm or whatever other system user) needs to be visible to the normal user when SDDM is used (and doesn't need to otherwise), but allowing it fixes the problem.

I noticed that console-kit-daemon --no-daemon is running as root (and is a funny self-contradicting command by the way), but it's also the case when starting Xorg manually.

I remembered facing the same issue while playing with XDM some time ago, so I tried again and noticed that the same behaviour also applies to XDM. LightDM on the contrary doesn't care and never failed to provide me with power buttons inside the Xorg session.
 
bsduck said:
I finally got it: the troublemaker is the sysctl security.bsd.see_other_uids being set to 0.
Click to expand...
Hello! Where do I find this setting to change it? Thanks.

EDIT: Found it in /etc/sysctl.conf
I commented it and this has populated the shutdown and reboot icons. Should I change it to "1" or something else though?
 
anarcho said:
Hello! Where do I find this setting to change it? Thanks.

EDIT: Found it in /etc/sysctl.conf
I commented it and this has populated the shutdown and reboot icons. Should I change it to "1" or something else though?
Click to expand...
Dunno what should work in your case... maybe play with that and report the results in this thread? 🤔
 
anarcho said:
I commented it and this has populated the shutdown and reboot icons. Should I change it to "1" or something else though?
Click to expand...
It's not necessary. The default value is 1 (users can see processes owned by other uids), so this is what will be enforced unless you explicitely set it to 0.
 
bsduck said:
I finally got it: the troublemaker is the sysctl security.bsd.see_other_uids being set to 0.
Click to expand...

anarcho said:
Hello! Where do I find this setting to change it? Thanks.

EDIT: Found it in /etc/sysctl.conf
Click to expand...

Either you put it there, or you had agreed to some offer to 'harden' security, without fully understanding (maybe serious) ramifications - possibly during bsdinstall or later in bsdconfig?

anarcho said:
I commented it and this has populated the shutdown and reboot icons. Should I change it to "1" or something else though?
Click to expand...

Ask for descriptions with
sysctl -d security.bsd
and you'll surmise that these are booleans; 0=no, 1=yes.

The same sort of restrictions may apply to the setting of

security.bsd.see_other_gids
 
You must log in or register to reply here.
Back
Top