Lockscreen while using authd with KDE
Is there an existing request for this feature?
- [x] I have searched the existing issues and found none that matched mine
Describe the feature
We are currently testing Ubuntu with authd for Entra ID login. This works well with Gnome. Is it also possible to use this setup with KDE?
In my setup with Ubuntu 24.04.2 LTS, where I just installed KDE, I can log in without problems, but I have issues when I lock my screen and then try to unlock. I get this error:
could not get current available brokers: permission denied: this action is only allowed for root users. Current user is [...]
I think the reason for this is that the KDE lockscreen is run as my own user account, whereas (as far as I understand) in Gnome, the lockscreen is provided by GDM.
I guess KDE (or other window managers) are not the main focus of authd, but still - if you have suggestions on how to make it work, that would be awesome!
Describe the ideal solution
No response
Alternatives and current workarounds
No response
System information and logs
Environment
- broker version: 0.2.0+33feab0.0d0d6c7
- authd version: 0.4.1
- gnome shell version: please run 46.3.1-1ubuntu1~24.04.1authd2
- Distribution: Ubuntu
- Distribution version: 24.04
Log files
Please redact/remove sensitive information:
Authd entries:
Mar 21 09:50:21 C-FKVZ6G3 systemd[1]: Starting authd.service - Authd daemon service...
Mar 21 09:50:21 C-FKVZ6G3 (authd)[2154]: authd.service: ConfigurationDirectory 'authd' already exists but the mode is different. (File system: 755 ConfigurationDirectoryMode: 700)
Mar 21 09:50:21 C-FKVZ6G3 systemd[1]: Started authd.service - Authd daemon service.
Mar 21 09:50:28 C-FKVZ6G3 authd[2154]: rpc error: code = InvalidArgument desc = no group name provided
...
Mar 21 10:49:32 C-FKVZ6G3 authd[2154]: rpc error: code = NotFound desc =
Mar 21 11:04:18 C-FKVZ6G3 authd[2154]: rpc error: code = NotFound desc =
Mar 21 11:04:31 C-FKVZ6G3 authd[2154]: rpc error: code = NotFound desc =
Mar 21 11:04:35 C-FKVZ6G3 authd[2154]: rpc error: code = NotFound desc =
Mar 21 11:06:39 C-FKVZ6G3 authd[2154]: rpc error: code = InvalidArgument desc = no user name provided
Mar 21 11:11:39 C-FKVZ6G3 authd[2154]: rpc error: code = NotFound desc =
Mar 21 11:11:39 C-FKVZ6G3 authd[2154]: rpc error: code = NotFound desc =
Mar 21 11:14:18 C-FKVZ6G3 authd[2154]: rpc error: code = NotFound desc =
Mar 21 11:14:18 C-FKVZ6G3 authd[2154]: rpc error: code = NotFound desc =
Mar 21 11:17:15 C-FKVZ6G3 authd[2154]: rpc error: code = NotFound desc =
and a bunch more NotFounds, nothing else since boot
MS Entra ID broker entries:
-- Boot 0048a962e3734ec9b2e4075b832d56f7 --
Mar 21 09:50:22 C-FKVZ6G3 systemd[1]: Started snap.authd-msentraid.authd-msentraid.service - Service for snap application authd-msentraid.authd-msentraid.
nothing else since boot
Google broker entries:
(not using google)
Application settings
Please redact/remove sensitive information:
MS Entra ID broker configuration:
cat /var/snap/authd-msentraid/current/broker.conf
MS Entra ID broker authd configuration:
probably not relevant, and only defaults except for issuer and client_id
Relevant information
No response
Double check your logs
- [x] I have redacted any sensitive information from the logs
Technically KDE would just work... But as per last time I tried, SSDM lacks of the full PAM implementation (for multiple conversations that are not a password) while locksceen may require some other love too.
As the last time I tried it was not running the pam instance as root (that we require to - avoid giving access to everyone to the authd socket).
It seems I'm also affected by this issue. Using i3wm and tried multiple screensavers (i3lock, xfce4-screensaver, gnome-screensaver). All failing with could not get current available brokers: permission denied: this action is only allowed for root users. Current user is XXX:
We only allow the root user to send PAM requests to authd since https://github.com/ubuntu/authd/pull/311. The reasoning on that PR is "To prevent spamming the service with invalid authentication request".
I wonder how feasible it is to protect against DoS from a local user. For example, all D-Bus services accessible to unprivileged users on the system bus are also prone to DoS (even though it's possible to restrict which D-Bus interfaces a process can use via D-Bus policies or AppArmor rules). IMO we should revisit this topic and in the meantime allow non-root users to authenticate to fix the issue with non-GNOME lock screens.
I wonder how feasible it is to protect against DoS from a local user. For example, all D-Bus services accessible to unprivileged users on the system bus are also prone to DoS (even though it's possible to restrict which D-Bus interfaces a process can use via D-Bus policies or AppArmor rules). IMO we should revisit this topic and in the meantime allow non-root users to authenticate to fix the issue with non-GNOME lock screens.
Yeah, this was something I had mentioned to the team in the past, since per se most PAM modules should not require being launched by root processes, however I think it should be simple enough to have an allow-list of PAM services that are still allowed as non-root if we want to still keep the behavior without breaking things that could work otherwise.
See also https://warthogs.atlassian.net/browse/UDENG-2694
Thanks for working on this. One doubt: So, authd needs an online authentication, even for the screen locker? If I'm offline (i.e. during a fly crossing the ocean), will I not be able to unlock the machine?
So, authd needs an online authentication, even for the screen locker? If I'm offline (i.e. during a fly crossing the ocean), will I not be able to unlock the machine?
No, it supports such context so unless enforced in the broker settings the user is allowed to login when offline for a while, see https://documentation.ubuntu.com/authd/en/latest/explanation/authd-architecture/
I've noticed that If I drop back to a TTY session, then switch back, it drops me into GDM and I can AuthD sign into my Same KDE session (and every window/app is still as I left it). If Only we could find a way to tell KDE to use GDM when the lockscreen function is kicked in.