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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
