>...Plus, there's a chicken and
>egg problem.  The server which gives you /dev/sd00/nvram
>has to approve of the attach when fossil wants to open its
>/dev/sd00/fossil, but until fossil has opened it, there's no
>way of knowing what's in /adm/users on that particular fossil.
>
>So for in-kernel file servers, it's best to look at them as hostowner
>and world and forget about groups.  For lib9p based servers,
>you can link in a different implementation of hasperm() and
>get whatever permissions checking you want, but the default
>behavior is to assume that the named group has exactly one
>member: the group leader.

Thank you for the clarification.  That's exactly what I'm getting at.
As you stated, /dev/sd00/* gets set up (especially where it's the only disk)
before we have any idea of what the users/groups look like.  Then, when you do
a ls -l, it will show you users and groups that are listed in /adm/users.
Chicken-and-egg, just like you said.  Of course, that lands us in the current
situation, where you can't tweak things such that 100% of all administration
activities can be performed remotely via drawterm... for some stuff like setting
up disks, one still has to use the local physical terminal.

Don't get me wrong... I'm not complaining or finger-pointing; I'm just trying to
fully understand the current state before attempting to poke at it.

Thanks much!!

-Ben