A brief note on 9vx and cpu, which might also be relevant for a few
other things. Using 9vx as a cpu server has been mentioned a few
times, but my attempts to actually get this working met with failure
initially. I believe I have tracked down the issue - the remoteside()
of cpu.c makes use of the kernel cap device via a call to the
auth_chuid function, and the cap device is not available in 9vx,
probably due to the single-user nature of it as a hosted environment.
If we don't need to support multiple users, there is an easy way to
get this work to work - just skip trying to change user.
cpu% diff /sys/src/cmd/cpu.c /sys/src/cmd/altcpu.c
590a591
> int factfd;
595,596c596
< if(auth_chuid(ai, nil) < 0)
< return -1;
---
> /* no cap device in 9vx so no auth_chuid, we are who we are */
597a598,601
> factfd = open("/srv/factotum", ORDWR);
> if(factfd >= 0)
> mount(fd, -1, "/mnt", MREPL, "");
> newns(user, nil); /* this and above 3 lines replicate auth_chuid
> behavior */
Because we aren't can't change user ID, using aux/listen as none isn't
going to work. Instead, we need to run the listener as our user, and
we can just put a factotum key in its namespace and leave out authsrv
and keyfs. Assuming the above modification has been compiled and
installed as altcpu, the following is all you need to do to allow
drawterm/cpu access:
term% auth/factotum
term% echo 'key proto=p9sk1 dom=testdom user=glenda
!password=password' >/mnt/factotum/ctl
term% aux/listen1 -t tcp!*!17010 /bin/altcpu -R &
Despite running as a trusted user, this should still be fairly secure
because cpu demands authentication. Even without authsrv/keyfs,
password-based authentication between the factotums works. Note
however that if you get the password wrong, it fails with a botch
message, so you have to redial if you typo your password. According to
my limited testing so far, cpu from plan 9 and drawterm both work
fine. This message was written in acme in drawterm to a 9vx elsewhere
on the LAN.
~Mycroftiv
9gridchan.org
