Re: Running pam-enabled /bin/login sessions in unprivileged terminal emulators

[nerdopolis <bluescreen_avenger@xxxxxxxxxxx>]

On Sunday, May 16, 2021 7:41:30 PM EDT  wrote:
> Hi 
> 
> I am trying to experiment around replacing the text mode TTYs with usermode
> utilities.
> 
> 
> While kmscon exists, the problem with it that I see is that it runs as root.
> It's most likely so it can run /bin/login as root, and /bin/login is not setuid
> 
> 
> I found that doing something like     (Can't fit the command in 80 chars, sorry)
>     systemd-run --setenv XDG_SEAT=$XDG_SEAT --setenv XDG_VTNR=$XDG_VTNR -t /bin/login -p
> can work in a way to run /bin/login within a non-privleged terminal emulator,
> however authentication is needed to run that command.
> 
> (there also seems to be no way to turn off the "press ^] to disconnect" option)
> 
> 
> 
> First question:
> Is there a supported way to allow a system user account to run one command
> without a password prompt with systemd-run? Otherwise I guess I can just make a
> setuid binary that calls the systemd-run command...
> 
> 
> 
> 
> The second thing: Things like nmtui need a full logind session to be able to
> run, and do polkit actions. However on seat0, it seems you need to decide on a
> empty TTY to use, which while you can use TTY63, that doesn't seem to be a 
> 'clean' idea.
> 
> 
> 
> One interesting workaround that DOES work is loading the vkms driver, adding
> the virtual card to a seat called 'seat-vtty' and then starting the login
> process on the virtual seat. That allows a full logind session to run and
> things like nmtui actually work 
>          modprobe vkms
>          loginctl attach seat-vtty /sys/devices/platform/vkms/drm/card1
>          systemd-run --setenv XDG_SEAT=seat-vtty -t /bin/login -p
> 
> 
> The fake video card device being added forces logind to create the seat-vtty
> seat. From that login prompt, I can log in and have polkit work, testing with
> nmtui. It's a bit odd having to use a virtual hardware device to make a fake
> seat, but it works to get around the TTY restriction for seat0...
> 
> Thanks
> 
> 
> 
Hi

I think I came up with a solution for myself for Question 1. I will have one
service start /bin/login in a PTY with socat, to a socket file with the
permissions set for the service user, and then socat running under a terminal
emulator that runs as the service user will connect. 

I actually already had some nice co-dependent .service files already, when I
first tried a socket based solution with tmux. But tmux was hard to nerf to be
"kiosk quality" to act similar to a login TTY. socat seems like it might be a
better fit, so I think I can call off having to worry about calling systemd-run
with a setuid binary, or making a complex polkit rule, or tweaking systemd-run
to disable the ^] disconnect ability...



Question 2, yeah it seems that manager_process_seat_device() is the only thing
that ends up calling seat_new() after some grepping, but I did find that if I 
set master-of-seat as a property a device, and add it with udev, I don't have
to use the vkms driver, instead I can say use /dev/tty or something, which is
at least cleaner than using a virtual display device 

Thanks



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel