You are not logged in.
Hi,
There's a problem I'd like to inform you about.
Maybe it's something in my configuration? Perhaps it's global?
Using sddm (LXQt), Services managed by OpenRC
Whenever you restart sddm, Regular users are being added to the root group.
Before, on any tty/psudeo-terminal:
$ groups
user cdrom floppy sudo audio dip video plugdev users netdev bluetooth lpadmin scanner incus-adminAfter:
On regular tty:
$ sudo rc-service sddm restartOn GUI psuedo-terminal (QTerminal):
$ groups
user root cdrom floppy sudo audio dip video plugdev users netdev bluetooth lpadmin scanner incus-admin
$ id
uid=1000(user) gid=1000(user) groups=1000(user),0(root),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),105(netdev),109(bluetooth),111(lpadmin),114(scanner),995(incus-admin)Worth to mention that:
The user is part of the root group only on GUI terminal (within LXQt) and not on regular ttys (if you'll run the groups command on a regular tty, this won't happen)
How can I fix it?
Update - I found out that it is a well known bug since 2018(!) how sad
Last edited by natanel (Yesterday 05:48:45)
Offline
I kinda solved my own problem until someone who knows how to help me will answer something much better:
Since using
rc-service sddm restartmakes you root the only workaround is to reinitiate everything, so on a true tty (Alt+F1-F6):
# telinit 1
...(go into runlevel 1, and then exit)
# exitIt's bad and probably not the best solution but I don't know how else to solve this problem, so for now, i'll simply restart pid 1
Important note - Do not perform telinit 1 (or any "sudo telinit ...") on a GUI terminal (QTerminal and so), do it on a regular tty because sddm breaks it and it won't send you back to a functional tty... (or is it just on my system?)
Again - this isn't a good solution, as it really messed my tap interfaces for incus...
It is also worth to mention that: If you sent yourself into single mode (
# telinit s) and then you're accidentally pressing f2-f7 to switch tty, all ttys will freeze including the single-mode one and become non-functioning, and then you won't be able to do anything except for magic sysrq (s+u+b) to force-reboot the machine
Last edited by natanel (Yesterday 06:37:23)
Offline
As a suggestion, you might try editing /etc/pam.d/sddm to make the line
@include common-authbe the two lines
@include common-auth
auth optional pam_group.soI'm hoping that might make the login procedure via sddm more aligned with the procedure of tty login and in particular add a pam_group.so call that seems to be missing. Though it's kind of an untested wild guess so don't hold your breath.
Offline
Nope ![]()
even after adding that line it still shows that I am part of root
Offline
Yeah I should really test it myself, but anyhow the second option would be to add the pam_group.so line at the top, to make it be:
auth required pam_permit.so
auth optional pam_group.soFor clairty although I'm pretty sure you did it; you must stop and restart the sddm service for testing.
Then, an alternative might be to add -g user to the sudo command so as to make the root user starting the service while in the user group.
Offline
I tried this one as well, but it still didn't worked. I edited
$ sudo vi /etc/pam.d/sddmand added those lines to the top of the file, but still:
$ sudo -g user rc-service sddm start
Starting Init script for Simple Desktop Display Manager: sddmstart-stop-daemon: unable to open pidfile '/var/run/sddm.pid' for writing (Permission denied)
start-stop-daemon: child returned error exit status 2
failed!Offline
Ah, I messed up; meant that those lines would be in /etc/pam.d/sddm-greeter
Offline
Seems like non of this works and at least for now the only way to solve it is to get into runlevel 1 (telinit 1) and then get back to telinit 2
Offline
Is the user actually added to the root group, or is it merely a case of group propagation in process exec chain? You can check with grep user /etc/group if user is in the root: line. (That file is the "groups database')
You might try again with "-g user" but make sure the old pid file is deleted beforehand; though it's slightly odd to get permission issue for non-root group. This is an attempt to avoid the root group in the process exec chain.
Offline
It isn't part of the root group, this only happens when restarting sddm
$ grep user /etc/group
cdrom:x:24:user
floppy:x:25:user
sudo:x:27:user
audio:x:29:pulse,user
dip:x:30:user
video:x:44:user
plugdev:x:46:user
users:x:100:user
netdev:x:105:user
bluetooth:x:109:user
lpadmin:x:111:user
scanner:x:114:saned,user
user:x:1000:
incus-admin:x:995:user
$ grep root /etc/group
root:x:0:Last edited by natanel (Yesterday 12:56:30)
Offline
Last year I discovered that its possible to login as root on a lightdm session: https://dev1galaxy.org/viewtopic.php?id=7430
Also posted this on the German Debian forum and had a chat about the issue on the Devuan IRC channel.
My final solution based on the feedback I got was:
Edit /etc/pam.d/lightdm past the entry „# Block login if they are globally disabled“.
# rolfie 02.10.2025, disable root login
auth required pam_succeed_if.so user != root quiet Perhaps you try the same with /etc/pam.d/sddm.
Last edited by rolfie (Yesterday 14:02:13)
Offline
That didn't solved it ![]()
But I was wondering, is it possible that the problem is caused by x11 and not sddm?
Maybe I need to check x11?
Offline
Looking at sddm source, it appears the user session process is started by uid root, so the subsequent groups fiddling (getgroups) will merge root's groups with the user's and set that for the process. In short it seems to boil down to crappy design. You'd do well in opting for some other "display manager".
Offline