Re(2): Current state of Vsta?

vandys@cisco.com writes:

>Since all connections are authenticated, I don't see the problem. You
>always know the identity of the connecting process.

Is it possible to know the pid of a process trying to connect?
That would be ideal. I seem to remember having to have the
kernel search through all the procs to find whose port it is.

>Even if you didn't want to depend on that, you could generate a 128-bit
>number which the connector had to supply before their connection would be
>accepted and used.

Yeah... (sigh) That would work, too.

>Right. Instead, VSTa tries to preserve the identity (i.e., mechanism)
>while leaving policy to the server. I think there's enough mechanism
>available to solve this problem.

There is, but I'm suggesting there might be a whole different way of
thinking about how servers are initiated and used.

I was playing a while ago with a modification to the library and dos
that would let you do things like:

mount //disk/fd:fd0!dos /floppy

The exclamation point here indicates that the next path element is
the name of a server that will operate on the path up to that point.
So it's really equivalent to saying:

dos -d //disk/fd:fd0 -n fs/dosfloppy &
mount fs/dosfloppy /floppy

In fact I originally devised it as a shorthand to doing that sort of
thing. But I realized that in this case there really is no need for a
global name at all. The only legitimate place that should have a
connection to that instance of dos is in my mount table. I can fork()
and clone() it to whoever needs it from there. So I made dos so it
skipped its normal authentication policies, and also added
reference counts so that it would automatically exit.

Then I realized you could do things like:

mount //fs/root:eric/mydiskimage!dos /image

as an ordinary user. The role of dos is different now. It's no longer
a system-level server, like wd, but more like a user-level utility,
like tar. It's simply performing a computational task on a file that
the user has access to. If the user has write access to that image
file, the user should be able to make changes to it. The user is
simply using dos as a utility function, an alternative to using the
hex editor.

So then I had to make dos skip ALL of its authentication and
policies, including access stuff. If the client said write, then dos
would try to write. Because dos has the same privileges as the
user, though, dos couldn't write the image file if the user couldn't.

The VSTa mechanism for identifying and authenticating users works
great, I think, for most system-wide, system-level services. You
can, I'm sure, get VSTa to do the things like the telnetd and the
dos thing either absolutely (checking the pid) or practically
(generating a 128-bit random number.) It's just an area of VSTa
that hasn't been developed much, in terms of convention even if no
new code needs to be written.

Just something to think about...
Received on Mon Aug 9 11:08:04 1999