> Since I'm not logged in as bootes, and am not a member of the > bootes group, I can't use con to connect to /srv/fscons, and > therefore, can't add a user.
That's correct. You want to change the policy, so that you are allowed to act as bootes occasionally. I see three reasonable ways to do that. The first is to put bootes's key in your factotum, after your own. Then when you want to connect to the cpu server you can cpu -k 'user=bootes', do what you need to do, and exit. The second is to make a console for each user who can run file server commands. You can issue additional srv commands in the file server config to create /srv/fscons.bhuntsman, etc., and then each user can connect to the one with the appropriate permissions. The third is to use consolefs, as Charles suggested, to moderate access to /srv/fscons. This has many benefits over the previous two ideas: the set of console users is defined in one easy place (the consolefs config), consolefs will multiplex output to multiple connections (unlike /srv/fscons, which is just a pipe and thus doesn't work so well with multiple readers), you can log the console output easily, and you can see what commands others are executing. The cpu or extra console solutions are fine if only one person (you) ever connects to the console. Once there is more than one person involved, consolefs is usually better. I use consolefs (with serial lines) for my own Plan 9 machines even when it's just me. One could imagine more complicated solutions, like writing servers that let certain users do certain restricted things, like create a new user but not execute other file server commands. It sounds like that's more complex than you actually need. All of these solutions assume that your normal user id should be allowed to connect to the file server console without additional authentication. You could also create a second user id (e.g., bhuntsman-sys) and require explicitly loading that user's credentials before connecting, if you were worried about accidental use. Russ
