[2765] in Release_Engineering

home help back first fref pref prev next nref lref last post

[daemon@ATHENA.MIT.EDU : add changes]

daemon@ATHENA.MIT.EDU (Calvin Clark)
Wed Apr 8 13:41:39 1992

Date: Wed, 8 Apr 92 13:41:01 -0400
From: Calvin Clark <ckclark@mit.edu>
To: mar@Athena.MIT.EDU
Cc: rel-eng@Athena.MIT.EDU, dryfoo@Athena.MIT.EDU
Reply-To: ckclark@mit.edu
In-Reply-To: [2761] in rel-eng

Two criticisms:

1. add -v locker results in :

	if: Expression syntax.

I know that the -v comes after the locker name.  Well, now I do.  I
tried the above syntax first, after hearing from someone about the new
'-v' flag to add.  Many novice users will make the same mistake.  If
users are advised to use `add' in their dotfiles, then the results will
be even more cryptic, because if they make this mistake, because they
will *still* get the error:

	if: Expression syntax.

even though "there is no `if' in my .environment file."  I can imagine
this resulting in a great deal of confusion.

2. `add locker -v' calls `attach' twice, thus obtaining mappings to the
NFS server twice, incrementing the reference counter on the server, etc.

I'm not sure how to put this kindly.  I guess this is a good example of
conservation of security.  After all of this hoopala about groveling
through /dev/kmem to remove tokens so that kernel hackers won't be able
to spoof users, it's a bit disappointing to see that the add alias stops
somewhere short of providing a user interface for comprimising security.
Yes, everyone's being moved to AFS, but that doesn't provide an excuse
for this; NFS service for people using the Athena Computing Environment
will be available for a long time, even if it's not widely used at MIT
in the future.  The NFS mapping-counter problem has been around for a
long time, and I agree that it's difficult to solve completely, but
there's no need to make it worse.

Please consider using an external script or program for use with add.
It will make it easier to design a robust interface.  The only major
disadvantages are (1) a possible minor decrease in performance and (2)
dependence on the existence and intregrity of the external program.  I
don't think (2) will be much of a problem, especially if the auxilliary
program/script put on the root partition.  As for (1), my guess is that
most of the time add takes up is spent it attach, and the wrapper around
attach will probably be relatively inexpensive.

-Calvin

home help back first fref pref prev next nref lref last post