Clients aren't given systemd session when logged in

[computerquip-work]

Doesn't seem to matter the method of login, after a fresh realm-join and ipa-client-install, I can login but the user can't use systemd utilities. Weirdly things like sudo work but things like systemctl --user or userdbctl do not. This appears to break things like cockpit. Relevant issue here: cockpit-project/cockpit#20150

Honestly, I'm not sure if this is the right place to file an issue. I can't seem to figure out the cause or if this is even a supported use case. I would assume that cockpit had assumed this case was supported else that issue wouldn't exist.

Any insight would be great, thanks in advance.

[sumit-bose]

Hi,

which version of SSSD and systemd are you using on which platform? There is an issue in some systemd versions where users with high POSIX IDs are not considered as regular users.

I guess your PAM configuration has something like

session    optional                                     pam_systemd.so

Please check if there are any log messages during login from pam_systemd or systemd-logind, if not maybe adding debug to the line above might help . I would expect that this module fails and if you replace optional with required in the PAM configuration login will fail.

bye,
Sumit

[alexey-tikhonov]

There is an issue in some systemd versions where users with high POSIX IDs are not considered as regular users.

Unfortunately, this is quite fundamental thing that isn't resolved upstream:

• journal: again create user journals for users with high uids systemd/systemd#30846
• Assign more UID range for regular users systemd/systemd#34617

[computerquip-work]

It's going to be a couple days till I can get back to it unfortunately, sorry for not providing more info up front. What I have off hand is:

• Fedora Server 41
• systemd version 256
• Based on distro version, it appears to use sssd 2.10
• I was able to see the user in userdbctl as root while the user was logged in over sshd (this indeed shows a high UID): https://gist.github.com/computerquip/705fed8aa29e6d3dfc55d88efd6e14a0
• There is no /run/user/$UID entry
• Cockpit appears to want a user session bus but one isn't available.

I'm not really sure what the workaround is. Is it unreasonable to expect this scenario at the moment?

[computerquip]

https://gist.github.com/computerquip/d9e3841518fee93dfb01ee1f951438e8 <- Slightly cleansed so I don't get hit with more bots.

As a side note, I can't seem to use userdbctl on the admin user now so I'm not clear on why I was able to previously but it was accurate. If I login with the domain user:

uid=1581400000([email protected])
gid=1581400000([email protected])
groups=1581400000([email protected])
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[alexey-tikhonov]

I don't think SSSD has anything to do with this.

[computerquip]

So just so I'm clear, IPA is assigning uids that are super high, systemd disagrees those are users and nobody on either side is reconciling. sssd is acting as the glue between the two and is sort of stuck in the middle. Does that about sum it up?

I'm still not clear on what my choices are exactly... Maybe I can figure out if FreeIPA can change uid/gid range or something and try that. Feel free to close the issue whenever I suppose, I can't close it from this account and it might be a couple days.

[sumit-bose]

Hi,

as long as you are using Fedora 41 there might be a different reason because it is working fine in my tests. E.g. I see

Mar 04 08:45:25 master.ipa.test systemd-logind[168]: New session 57 of user testuser.
Mar 04 08:45:25 master.ipa.test systemd[1]: Created slice user-1543200006.slice - User Slice of UID 1543200006.
Mar 04 08:45:25 master.ipa.test systemd[1]: Starting [email protected] - User Runtime Directory /run/user/1543200006...
Mar 04 08:45:25 master.ipa.test systemd[1]: Finished [email protected] - User Runtime Directory /run/user/1543200006.
Mar 04 08:45:25 master.ipa.test systemd[1]: Starting [email protected] - User Manager for UID 1543200006...
Mar 04 08:45:25 master.ipa.test systemd-logind[168]: New session 58 of user testuser.
Mar 04 08:45:25 master.ipa.test (systemd)[1059]: pam_unix(systemd-user:session): session opened for user testuser(uid=1543200006) by testuser(uid=0)
Mar 04 08:45:25 master.ipa.test systemd[1059]: Queued start job for default target default.target.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Created slice app.slice - User Application Slice.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Started systemd-tmpfiles-clean.timer - Daily Cleanup of User's Temporary Directories.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Reached target paths.target - Paths.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Reached target timers.target - Timers.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Starting dbus.socket - D-Bus User Message Bus Socket...
Mar 04 08:45:25 master.ipa.test systemd[1059]: Listening on pipewire-pulse.socket - PipeWire PulseAudio.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Listening on pipewire.socket - PipeWire Multimedia System Sockets.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Starting systemd-tmpfiles-setup.service - Create User Files and Directories...
Mar 04 08:45:25 master.ipa.test systemd[1059]: Finished systemd-tmpfiles-setup.service - Create User Files and Directories.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Listening on dbus.socket - D-Bus User Message Bus Socket.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Reached target sockets.target - Sockets.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Reached target basic.target - Basic System.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Reached target default.target - Main User Target.
Mar 04 08:45:25 master.ipa.test systemd[1059]: Startup finished in 88ms.
Mar 04 08:45:25 master.ipa.test systemd[1]: Started [email protected] - User Manager for UID 1543200006.
Mar 04 08:45:25 master.ipa.test systemd[1]: Started session-57.scope - Session 57 of User testuser.

where you are seeing the pam_systemd error messages in the logs. Have you checked is there are e.g. from SELinux AVCs in the audit logs?

bye,
Sumit