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

[nerdopolis <bluescreen_avenger@xxxxxxxxxxx>]

On Thursday, May 20, 2021 10:53:24 AM EDT  wrote:
> On So, 16.05.21 19:41, nerdopolis (bluescreen_avenger at verizon.net) wrote:
> 
> > Hi
> >
> > I am trying to experiment around replacing the text mode TTYs with usermode
> > utilities.
> 
> I don't follow?
>


I am sorry, I will try to be more clear. That first email, went through several
drafts, as at first it was longer and rambly, and I didn't want to bombard the 
list with a giant wall of text.


(I actually found my solution was to use socat since sending that last email.)


I was seeking some more existing programs I could try to cobble together to 
come up with a solution. The main things were:
     1. /bin/login needs to be run as root for it to work
     2. It's ill-advised to start a graphical terminal emulator as root
- I looked into the existing kmscon, but it's older, and ran as root

- I tried running tmux client/server with the server as root, the client as 
  non-root. It worked in theory, but tmux didn't seem fit to run ONLY a login
  prompt

- I tried using systemd-run, but it had the quirks I described

BUT
- I found I could do the same client-server thing with socat, not tmux. tmux
  has a basic way to forward a PTY to a socket, and then set the permissions on
  it for a non-root system user, and then connect to it from a command running
  under a terminal emulator running as that non-root user.


So my solution ended up being something like: 
-------------------------------------------------------------------------------
vtty-backend@tty1.service(u:root)                 vtty-frontend@tty1.service(u:vtty)
   socat exec:/bin/login unix-listen:/run/socket    cage (wayland)
                                       /|\           vte (terminal emulator)
                                        |             socat file:`tty` unix-connect:/run/socket<-|
                                        |________________________________________________________|
-------------------------------------------------------------------------------

That way there I was able to solve the first issue. (and actually the second 
issue too, by running the backend on a fake seat-vtty seat)
> > 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.
> 
> hmm? XDG_VTNR is for the Linux VT subsystem but though i don't
> understand what you are trying to do i get the impression you don't
> want to use VTs? or do you? not following...
> 
Sorry, I got the terminology mixed up again. I am still using TTYs to run the
instances of `cage`. It's the kernel mode VT emulators I am replacing with the
user mode terminal emulators (running under a fullscreen Wayland compositor)
> > 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...
> 
> It's PolicyKit enabled, you can allow your user to run unpriv
> commands, but it's a all-or-nothing thing.
>

OK, that's kind of what I thought. Thanks for confirming. (If I hadn't found 
the other solution, I would have just made the setuid binary for kicking off
systemd-run)
> > 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.
> 
> Can't parse this, sorry.
> 

I am sorry I was not clear, I'll try to use nmtui as an example to describe
what I am seeing.

nmtui is an example of a utility that needs polkit (or root) to work. It comes
with NetworkManager. Start nmtui from a normal terminal emulator, or a classic
tty, and you likely will be able to edit connections with it.

Now if you do 
    systemd-run -t /bin/login -p
and then login, and run nmtui, that instance will then say "not authorized" 

I forgot what inspired me to experiment with setting XDG_SEAT but if you 
    systemd-run -t --setenv=XDG_SEAT=seat0 /bin/login -p
and then log in, and nmtui still doesn't work. 

Check the journal, you will get an error "failed to create session: VT number 
out of range" where the VT number that gets logged is 0. I guess it fails
because on seat0 VT numbers can't be 0.

  - one ugly hack though was setting XDG_VTNR to like 63 or something



What DOES work is if you create a second seat somehow called seat-vtty then:
          systemd-run -t --setenv=XDG_SEAT=seat-vtty /bin/login -p
and login, and THAT WORKS. because the non-seat0 seat accepts a VTNR of 0
>From within that session, you can edit connections with nmtui again.


I hope this clarifies some things, I was able to solve with with using the
socat proxy, so I think I might be all set. Although this might be a good case
to where XDG_VTNR=0 might actually be _valid_ for seat0... Not sure if I should
open a case for that, (or not, if it's going to break compatibility)

Thanks
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 
> 




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