+From: SMTP%"[EMAIL PROTECTED]" 14-APR-1993 12:34:48.15
+To: [EMAIL PROTECTED]
+CC:
+Subj: Re: PAG Instructions, Please
+Message-Id: <[EMAIL PROTECTED]>
+To: [EMAIL PROTECTED]
+Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
+Subject: Re: PAG Instructions, Please
+In-Reply-To: Your message of "Tue, 13 Apr 93 22:41:03 CDT."
+ <[EMAIL PROTECTED]>
+Date: Wed, 14 Apr 93 13:34:32 -0400
+From: [EMAIL PROTECTED]
====== The following material was relocated from the end of the message ======
++> I feel that the fact that ``quite a bit of user retraining''
++> is required shows that something is broke.
+Um, - well, the computer industry was the wrong thing to go into,
+if you want a stable non-changing environment. The computer
+world was very different 10 years ago (Remember Codata?
+Wicat? DEC Vax? VMS? Multics?) I expect it will be very
+different 10 years from now. I, for one, welcome such change.
+For me, the neat thing about Unix is how successful it has
+been at evolving with the technology and taking advantage of it.
+"MVS" is a good example of what happens when you work
+hard to avoid the need for "user retraining". I wonder just how
+many card decks got turned into MVS files and are still used today?
:-} This reply was prepared and sent from a DEC VAX computer
running DEC VMS 5.5 operating system. Yes, I remember them.
I studied the Multics operating system to understand how
it lead to the design of the UNIX operating system. There
is a relationship here.
As for a trip down memory lane, I remember the IBM 650
with the main memory being a mechanical rotating magnetic drum.
Many of the computers I worked on in my early days had
ferrite core memories (non-volatile by physics and design).
Do you remember IBM TSS? I used to debug the Resident
Supervisor. How about BPS, BOS, TOS, OS/PCP, OS/MFT I,
OS/MFT II and OS/MVT (I still have my system generation tapes,
some logic manuals and microfiche).
I do not object to some ``user retraining''; I do object to
``quite a bit of user retraining''. I used to do operating
system support including problem determination on the IBM
MVS operating system. I remember that IBM did try very
hard to eliminate any need to recompile executables or
retrain user, *if you did not need to the new features
of the operating system or improved performance.*
+None of this means that AFS does it best, or that you shouldn't
+scream bloody murder when AFS doesn't do something the same
+as Unix. It just means you should first ask "Why isn't this
+done the same way" and "How could it be done to better
+preserve the Unix semanantics"? (Perhaps followed by "did
+DFS do it that better way" and "when will DFS be out? :-))
I agree with you. I am not screaming "bloody murder";
I am saying "here be dragons."
If ACLs were layered on top of the UNIX semantics so that
I had a choice of either or both, I would find that sufficient.
I certain hope that DFS did it better. I do ask when will
DFS be available.
====== The end of relocated material ======
+In all of the following, one thing to keep in mind. There
+are no "wrong questions" or "right answers". Only "different
+perspectives". Looking at things throught other people's
+perspectives is sometimes illuminating - let me share my
+perspective with you.
Thank you. I frequently learn from other's prespectives.
[EMAIL PROTECTED] (Randolph J. Herber, CD/DCD/SPG, x2966) writes:
++> Another thing I do not understand is why AFS did not implement full Unix file
++> semantics and instead implemented ``ACL''s.
+This is really an "elementary" part of AFS - they *had* to do this
+to accomplish their goals of working in large environments.
I disagree.
+Unix file permissions were clearly designed for the use of small to medium
+groups that do not need very sophisicated file protection schemes, and as
+extended by Berkeley ("setgroups") it requires the agency of some central
+authority to manage a file "/etc/groups" to control what groups people belong to.
I must agree. It breaks down without good user identification
adminstration and when large numbers of groups are needed.
I have seen it work quite well when these conditions are met.
(The example I have in mind is AT&T Bell Labs.)
+Unix permissions are clearly not well suited for the use of
+a very large scattered organization - you may have many workgroups
+who will want very fine grained control over who can access
+a given file - say, "everybody in the workstation systems group
+may read stuff in this directory, except for Joe who is an asshole."
+In a large organization, you may end up with hundreds, or even
+thousands, of such "needs" for file protection - this information
+clearly ought to be associated with the file or directory, and
+controlled by the user or group who "owns" that storage.
+Storing it anywhere else, such as /etc/group is ugly at best,
+and unmanageable at worst.
My objection was not to ACLs. My objection was to ACLs
instead of the customary UNIX semantics.
+In our organization, the University of Michigan, many people are used
+to, and make full use of, the file permissions model of MTS. MTS,
+somewhat like AFS, makes it possible to permit files to groups or
+individual users, although MTS groups are not as flexible as AFS.
+Their question with IFS will not be "why do you have ACL's" but rather
+"why do ACL's apply to directories not files?" Of course, as you
+might expect, that's yet another DFS feature. If we made
+plain Unix file permissions available out there, there'd be
+such a hue & cry...!
With respect to "plain Unix file permissions", `instead of'
or `in addition to' causes "such a hue & cry...!"?
I imagine it is the `instead of' case that would be objected to.
[EMAIL PROTECTED] (Randolph J. Herber, CD/DCD/SPG, x2966) goes on to write:
++> When I can not run set-uid and set-gid programs in the form they
++> were developed, I feel something is broke.
++> When I can not run programs without making them also readable,
++> I feel something is broke.
+In a large networked world, you need to assume that people can break
+in and compromise machines, or masquerade as otherwise non-existant
+new clients. Remember, you are usually talking about many hundreds
+of machines scattered over a wide area - it is not feasible
+to post armed guards over every machine and connect them with pressurized
+network connections patrolled by guard dogs. Yet, with NFS,
+that is precisely what you would need to do, to run a secure
+system over the area of, say, Ann Arbor. Anyone who can type L1-A can
+"read" a program from NFS. Anyone who can alter their UID or GID,
+or write an RPC interface to NFS, can get around NFS file permissions.
At this level, is AFS any more secure?
+With AFS, file permission is built on top of kerberos style
+protection technology. You have access to something if you
+know the key. There's no way the file server can know if
+you are really the kernel trying to load a program, or a user
+trying to "cp" the file - so why pretend "execute only" permission
+exists when the concept is in fact meaningless in a networked
+world? Basically, the concept of being "SUID" just does not
+make sense in a distributed environment - you need to remodel
+such things into a "server/client" type paradigm, where the
+server runs in a trusted secure environment and has keys to do its thing,
+and clients run in a non-trusted unsecure environment and could be
+anything - why not define an open protocol & invite people to write
+their own improved clients?
This appears to be a reasonable remapping of the setuid
idea. The program being marked as having the permissions
of another user even when being executed by a different user.
There could be network-wide or cell-wide (and so forth)
user identifications that would be the moral equivalent
of `root' that such programs, resident under AFS control,
could be `set uid' to.
+ -Marcus Watts
+ UM ITD RS Umich Systems Group
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.)
