+To: [EMAIL PROTECTED]
+Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
+ [EMAIL PROTECTED]
+Subject: Re: PAG Instructions, Please
+Date: Wed, 14 Apr 1993 12:49:36 -0400
+From: "Michael T. Stolarchuk" <[EMAIL PROTECTED]>
+Mostly I'm quiet when it comes to messages like this, but
+I don't think I agree with much of what is being said
+by Herber...
+ "No! AFS runs in a AFS environment.
+ The UNIX operating system is a support environment for AFS;
+ not the converse."
+I don't think so. In fact, most of the traditional tools
+work just fine, and the servers have to bend over backwards
+trying to deal with old silly semantics (non distributed
+file system semantics). For example, even if you can't write
+the file, if it was just creat'd, and you did the creat,
+then you can write the file....
I do not think that the UNIX file system semantics are "old silly".
Let distributed file systems support full UNIX file semantics
in addition to any additional semantics. Also, allow the
ability to turn off the additional semantics if they are
not wanted (e.g. ACL's).
+I think it was real nice that AFS appeared with Unix, cause
+otherwise we would have had to scrap Unix's over time,
+cause it wasn't dealing well with the distributed file
+systems... I would likely have a novell/banyan file server.
AFS did not appear with the UNIX operating system.
The UNIX operating system is at least two decades older.
+ "When I can not run set-uid and set-gid programs in the form they
+ were developed, I feel something is broke."
+Big mistake here. Most admins curse the set-uid patent.
+Most system programmers will never admit to writing a
+good set-uid program. Given the most recent troubles
+with rdist, I doub't any truly correct set-uid programs can
+be written.
I agree that setuid and setgid programs are very difficult
to write correctly.
+BTW: what exactly do you mean by suid in a network?
+does the suid pass through the network? So that some other
+czech-admined process-oriented NFS server could deliver
+to you a suid program, and you want it to run as root?
If I trust the identification of identity, the server,
the network and the client, yes -- I want to run it as root.
If I did not trust any of these, then I did not
want to execute the program, period.
+What about suid on non root, when you can't get
+a congruent uid image? (ie: who's uid so and so,
+cause that's a local administration issue)
This is a problem with any network with more than one
machine on it. The question is how to handle any
user identifiers between systems. This is not just
a local administration issue; it is an administration
issue, period. Foreign users must be mapped to be
semantically equivalent to a user with only `world'
access rights.
+It was with great relief that AFS provides little meaning for
+root. This was among the first great victories.
Any network file system needs to have the capacity to
disenfranchise any identification or element.
+ "When I can not run programs without making them also readable,
+ I feel something is broke."
+In a distributed file system sense, if you can execute the file,
+you've read the file. I can always grunge around in my cache
+to collect a file read from the server.
Then, your client is not trustworthy.
+An alternative is to encrypt the data for an executable under
+a session key established for the duration of the connection,
+based on some principle (the machine I'd assume); but
+even if I could live with the key distribution problems,
+broken (fixed-in-the-right-way) kernels would still allow me
+to save the executable images, since the machine can't
+run encrypted data streams.
Yes, this needs to be implemented on an optional basis.
+ "I feel that the fact that ``quite a bit of user retraining''
+ is required shows that something is broke."
+We've got this neat project called 'disconnect AFS' which
+solves lots of troublesome AFS issues, and causes new ones...
+The net benefit is positive, but it requires understanding
+more of what is going on. I believe (as other do), that
+some of the users will be willing to deal with the
+additional things they need to learn...like reconcilitaion...
+ "When AFS or its successor is as transparent to the user as
+ NFS is, then it will be repaired."
+I'm surprised about this comparision. Ever get a 'Network timed out' error
+while writing an NFS file via 'vi'? I wouldn't consider that
+transparent....
I used a comparative. I did not say that BFS was tranparent.
I only asked that AFS be as tranparent as NFS. AFS is not.
+Or how about a 'pwd' from NFS while using the automounter. What's
+that path name mean? Or other interesting NFS behaviors, like
+'what's that extra file in my directory when I unlink files?'
I do not use automounters, partly for that reason.
+Or how about 'ls -l', and getting wild owners...
That is an administration issue. :-) :-) Maybe world-wide
identification numbers issued at the time of the creation
of the legal person (birth, incorporation, etc.) With 64-bit
uids? (-: (-:
+mts.
+I figured a NON transarc person ought to defend AFS.
Randolph J. Herber, [EMAIL PROTECTED], +1 708 840 2966, CD/DCD/SPG
(Speaking for myself and not for US, US DOE, FNAL nor URA.)
(Product, trade, or service marks herein belong to their respective owners.)
