Some methods of getting a "login shell" do not create /run/user/<uid> or add a session to loginctl

Some methods of getting a "login shell" do not create /run/user/<uid> or add a session to loginctl

[Ben Weinstein-Raun]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

I've noticed that several methods of opening a "login shell" do not
result in the XDG_RUNTIME_DIR (/run/user/<uid>) being created; and also
don't result in a session appearing in the output of `loginctl`:


* `mosh`
* `sudo -i <user> loginctl`
* `su -l <user>`
* `login`

I mentioned in another message that I'm hoping to write a system
shepherd service that will start a user-level shepherd service. But a
user-level shepherd services won't run without the XDG_RUNTIME_DIR (or
some other explicitly-chosen suitable directory, but I'd prefer not to
deviate from the defaults, if I could instead understand what's going on).

Does anyone know why this would happen, or how to fix it? I'm using the
elogind service on top of %base-services.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: Some methods of getting a "login shell" do not create /run/user/<uid> or add a session to loginctl

[Skyler Ferris]

On 12/30/23 04:45, Ben Weinstein-Raun wrote:

> Does anyone know why this would happen, or how to fix it? I'm using the
> elogind service on top of %base-services.
>
I was hoping that someone else more knowledgeable might have a better 
solution, but since nobody has replied I'll share the less-than-ideal 
solution I've been using. I use a system without elogind, so I'm not 
sure if there would be a conflict with this setup and that service. 
Also, this solution does not properly destroy the directory when a user 
fully logs out, only when the system is rebooted.

Basically, I just use some code to mount tmpfs onto the directories by 
adding extra values to the file-systems declaration of my 
operating-system declaration. The main disadvantage not already 
mentioned is that UIDs and GIDs have to be explicitly defined for each 
non-system user. Maybe the logic for the GIDs could be removed because 
the group has no permissions on the directory anyway, but I haven't 
thought it through.. There are some helper functions:

(let*
     ((get-gid-by-name (lambda (name groups)
          (let ((matches (filter (lambda (group) (string=? 
(guix.user-group-name group)) name)
                                 groups)))
              (if (>= (length matches) 1)
                  (guix.user-group-id (car matches))
                  (error (string-append "The group " name " must have an 
explicitly defined GID!"
                                        " Add a (gid <number>) form to 
the group definition."))))))

      (get-user-gid (lambda (user groups)
          (unless (guix.user-account-group user)
              (error (string-append "The user " (guix.user-account-name 
user)
                                    " must have an explicitly defined 
group! Add"
                                    " (group <name|number>) to the user 
definition.")))

          (let ((gid (if (number? (guix.user-account-group user))
                         (guix.user-account-group user)
                         (get-gid-by-name (guix.user-account-group user) 
groups))))
              (number->string gid))))

      (get-user-uid (lambda (user)
          (unless (guix.user-account-uid user)
              (error (string-append "The user " (guix.user-account-name 
user)
                                    " must have an explicitly defined 
UID! Add (uid <number>) to"
                                    " the user definition.")))
          (number->string (guix.user-account-uid user)))))

Which can then be used to create the filesystems:

(map (lambda (user)
                     (let ((uid (get-user-uid user))
                           (gid (get-user-gid user groups)))
                         (guix.file-system
                             ; I don't know if this is normally a tmpfs, 
but the XDG basedir standard
                             ; says that it MUST not survive a reboot, 
so being tmpfs shouldn't cause any
                             ; problems. This is technically not 
compliant because it also says that the
                             ; contents MUST be removed if the user 
fully logs out (implicitly, even if
                             ; the system remains powered on) and I'm 
not doing that. It looks like guix
                             ; has a predefined greetd configuration to 
handle this correctly.
                             (device              "tmpfs")
                             (mount-point         (string-append 
"/run/user/" uid))
                             (type                "tmpfs")
                             (check?              #f)
                             (options             (format #f 
"mode=0700,uid=~a,gid=~a" uid gid))
                             (create-mount-point? #t))))
                     (filter (negate guix.user-account-system?) users)))))

Regards,
Skyler

Re: Some methods of getting a "login shell" do not create /run/user/<uid> or add a session to loginctl

[Ben Weinstein-Raun]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On 01/05/24 14:39, Skyler Ferris wrote:
> I was hoping that someone else more knowledgeable might have a better 
> solution, but since nobody has replied I'll share the less-than-ideal 
> solution I've been using.
Thanks a lot for the response!

> Basically, I just use some code to mount tmpfs onto the directories by 
> adding extra values to the file-systems declaration of my 
> operating-system declaration. The main disadvantage not already 
> mentioned is that UIDs and GIDs have to be explicitly defined for each 
> non-system user. Maybe the logic for the GIDs could be removed because 
> the group has no permissions on the directory anyway, but I haven't 
> thought it through.. There are some helper functions:


This is super useful, thank you! And probably substantially better than
my current hack (brute `mkdir -p` on startup, which seems likely to make
`mount` sad when later someone *does* log in properly, let alone the
issue you mention with surviving reboots).



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]