--lyndon
This solution didn't work because groups are specific to the
file server implementing them. Your CPU server doesn't know
about the groups on your file servers and doesn't itself
implement any groups.
You could hack up a copy of srvfs that looks at the user
name being presented over the 9P connection and makes
the decision that way, or you could write a custom file server
with its own group list, like consolefs has.
Russ
This seems to make the most sense. And it makes it simple to implement
(configurable) exclusive open semantics for devices that need it.
--lyndon
I'm suffering more 2ed->4ed migration brain damage. After reading through
some of the assorted fileserver code I see what you mean. The [m][ug]id
fields in stat seem somewhat arbitrary these days.
It might be nice if fileservers that just make up [ug]ids to satisfy stat
or otherwise ignore permissions returned 'none' or something equivalent in
those fields, just as a hint.
--lyndon
what is importfs?
if you mean exportfs, it's not going to do what lyndon wants
you can import devices as a normal user
; import -E ssl minooka.coraid.com '#æ' /n/mæ
but that doesn't change the system's idea of who you are
; cd /n/mæ/aoe && ls -l
--rw-r--r-- M 71124 bootes bootes 0 Oct 28 12:26 ctl
--r--r--r-- M 71124 bootes bootes 0 Oct 28 12:26 log
; echo bind '#l1/ether1' > ctl
ctl: rc: can't open: 'ctl' './aoe/ctl' permission denied
you can import as another user, say bootes. but in order to
do that, every member of the group has to have bootes'
password. but if that were the case, lyndon's users could just
cpu in as bootes.
- erik