Excerpts from mail: 10-Feb-94 Re: PC Interconnection usin..
[EMAIL PROTECTED] (1662)
> Once client ``login'' is complete, the common code forks specific UNIX
> process [aka pcidossvr] that is per ``PC'' that runs as that person
> [i.e. clemc/bob/dmr etc]. It is the pcidossvr process that does a work
> on behalf of a user.
> Thus, in order the use the AFS token [which is shared in the AFS client
> cache], a random PC must still reconnect the the PC-I server. Since the
> PC-I ``sessions'' are not shared, you get protection.
> NFS uses a common set of remote processes for everyone, hense once the
> AFS authenication is done, an other system that can forge a UID has
> access. Hense you have a hole.
It is unfortunate that you do things this way.
With MIT networking the dorms, and serving its users with AFS, one can
expect that PC and Mac users at MIT will be interested in AFS access.
Unfortunately, a process per PC would not scale in our environment.
While I agree that your process per PC model does side step the security
problem inherint in unmodified NFS, it seems an awfully high price to
pay. You could do just as well with a simple UID mapping scheme and a
single process model. It is one of my deepest professional regrets that
vendors are thinking in terms of less than 100 clients of their
services, and choosing dead-end algorigthms when a little extra thought
would result in more robust, and larger scale products.
-Bill Cattey
MIT Information Systems
Notable quote:
-What part of "6000 unique logins per day, 1000 public access
workstations, a network drop per student in a community of 15,000,
arranged into 100 subnets" didn't you understand?
