[9fans] 9vx access from Drawterm/cpu: patch and how-to
mycroftiv 9gridchan
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
Tim Newsham
> 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.
I dont understand. Why can't the capability device be put directly
into 9vx? Doesn't the 9vx "kernel" have its own notion of
user id for each of the processes it hosts independant of the
underlying unix user id? I thought only select parts of the
system such as the unix file server cared about the unix
user id.
> ~Mycroftiv
> 9gridchan.org
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
mycroftiv 9gridchan
>into 9vx? Doesn't the 9vx "kernel" have its own notion of
>user id for each of the processes it hosts independant of the
>underlying unix user id? I thought only select parts of the
>system such as the unix file server cared about the unix
>user id.
I didn't mean to imply that the capability device couldn't exist
within 9vx, simply that it was not currently implemented. I speculate
the reason it hadn't been done was that 9vx wasn't really conceived as
a multi-user system. I wasn't proposing my patch as anything other
than an expedient means of getting CPU functionality within an
existing 9vx setup. I confess I haven't taken the time to study what's
really going on in the .ed files used to tweak the plan 9 source for
9vx, and I didn't have a personal practical motivation for doing more
than just cpu in as the current user. I think the general issue of how
to make 9vx as close a parallel to a native plan 9 install as
possible, including support for tcp booting, plan9.ini options,
running the standard file servers from disk partitions, would benefit
from being addressed in an integrated way. I know some of this work
has already been done. A 9vx distribution with those modifications and
the full tree included would be a fun project, but the 'too many
projects, too little time' issue always looms.
>Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
~Mycroftiv
9gridchan.org