Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.admin
Subject: Re: Project Athena ( was Re: Non Destructive Version of rm)
Message-ID: <1991May8.174603.26309@athena.mit.edu>
Date: 8 May 91 17:46:03 GMT
References: <12049@mentor.cc.purdue.edu>
Sender: news@athena.mit.edu (News system)
Distribution: na
Organization: Massachusetts Institute of Technology
Lines: 175

In article <12049@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes:
|> The old Iidea that "it is a good idea if people put money into it" Remember
|> the HUNDREDS OF MILLIONS SPENT ON PET ROCKS?? THe fact that money has been
|> put into the project is not indicative of Project Athena's worthefullness.
|> Ford put alot of money into the Edsel.

  The *facts* are: people are willing to invest in distributed computing
research; the computing industry has been devoting huge amounts of resources
to developing distributed computing; the computer industry's journals (such as
the CACM and others) have discussed at length, many times, the advantages (and
disadvantages) and recent developments in distributed computing; and there
seems to be almost unanimous agreement both in academic and industry circles
that distributed computing is worth pursuing as at least on alternative in the
long list of ways to compute.

  In the face of this, you come along and assert that distributed computing is
a bad idea.

  You are entitled to your opinion, Bruce.  However, asserting that something
is fact does not make it so.  If you want to convince people that distributed
computing is a bad idea, you're going to have to do more than assert it, and
so far, that's all you've done.

|> }one of our workstations (or public workstation root password is "mroot";
|> [Give me the addresses (or do I have to log in from the console?)]

  Public workstations, with the public root password, do not allow remote
access.  Machines that do allow remote access have a different root password.

|> Oh, I like your setup even better now. Give all the users root! Very
|> tidy, and secure.

  Root access on a public workstation grants no special powers in our
environment.  As I said, I will not debate that here.

|> You were complaining aboutquota's earlier and you 
|> give you users all root privs?????????

  We give all users root privileges on public workstations.  That does not
give them any access they should not have to our services.  As I said, I will
not debate that here.

|> I know. That is the reason for the
|> elaborate autentication system - but tell me, if you dinna let your
|> users have root privs would you NEED the elaborate authentication
|> system?

  Yes, because it is impossible to insure that every machine on a network is
secure.  We have a huge wide-area campus area network, with machines on it
that are run by many different organizations, departments, etc.  We have Macs
and PCs on the network that don't even have any *concept* of root privileges. 
When you cannot assume that root is secure on all machines on a network, then
you must assume that it is *not* secure, and that is why the decision not to
hide the public workstation root password was made.

  One more time: I discussed all this in alt.security.  I will not debate it
again here.

|> And giving away root privs is. What is the purpose of having semarate 
|> accounts then? Or do you have to give some kind of Kerberos authentication code
|> for every damn thing you do?

  Once again, "If you don't know how Project Athena works, don't slam it."

  Kerberos authentication is, for the most part, completely transparent to the
user.  To a Project Athena user, logging into one of our workstations is no
different from someone logging in at Purdue.  It was designed with that goal
in mind.

  If you don't understand how this can be so, I suggest you learn more about
Project Athena, or be quiet.

|> }  Running commands is different from manipulating files.  There are very few
|> }programs which manipulate files that allow the user to specify a filename and
|> }know where to find it automatically.  And those programs that do have this
|> }functionality do so by either (a) always looking in the same place, or (b)
|> }looking in a limited path of places (TEXINPUTS comes to mind).  I don't know
|> }of any Unix program which, by default, takes the filename specified by the
|> }user and searches the entire filesystem looking for it.  And no, find doesn't
|> 
|> I did not propose looking through the whole filesystem, just looking
|> through a certain number of specific places (the tomb directories). In fact,
|> you only have to look in one at a time (the tomb dir on your filesystem).

  You're mixing apple with oranges.  I asserted that it was a flaw not to
remember when archiving deleted files where they were in the original
filesystem.  You responded by asserting that it is a flaw that a user has to
remember where files were originally when undeleting them.  I responded that
*every* Unix utility requires users to remembers where files are.  Now you're
talking about remembering where the files are entombed, which is a completely
different issue.

|> and users being allowed to moun other directories
|> at will,

  Users being allowed to mount other directories at will is a logical
extension to the ability to mount remote filesystems.  Placing unnecessary
restrictions on the user is antithetical to the original design goals of Unix,
and furthermore, it's counterproductive.  If it is technically feasible to
allow arbitrary filesystems to be mounted by the user, I fail to see how you
can call it a kludge.

  Incidentally, both DEC and Sun both ship a version of mount that allows
non-root users to do NFS mounts.  I guess they don't think it's a kludge
either.  Oh, I know what you're going to say, "The fact that other people are
doing it doesn't mean it's right."  Fine, but the fact that other people are
doing it provides a proponderance of evidence that it *may* be right, and you
can't disprove that just by asserting otherwise.

|> and users being given the root pasword, and then creating an
|> authentication system to close up the wholes made by giving users access
|> to root privs  - now *THAT* is a kludge.

  The authentication system is designed to fix the fact that networks are not
secure, and that you can never assume that every machine on your network is
secure.  Especially not on the Internet, when we *know* that this is not the
case.  This was discussed at length in alt.security.

|> I think that there are other viable solutions. But as I said, it is
|> still possible to handle users directories on a net of 1000 workstations
|> without your ridiculous kludge. As GE has done.

  GE does it by cross-mounting all filesystems via NFS on all machines, right?
Is it really true that you have 1000 machines, with all filesystems mounted on
all of them?  I find that somewhat hard to believe.

  In any case, you're right, it is possible to do it without explicit
mounting.  That's why we're working more and more with the Andrew File System
(AFS) here at Athena.  However, there are still advantages to being able to
mount filesystems arbitrarily, since many people are going to be using NFS for
a long time into the future, even if we start using AFS internally.

|> first - I said appearantly, which denotes some measure of uncertainty. 
|> Second - Well, I just don't think it is wise to allow others to mount
|> filesystems when and where they want at will.

  The industry appears to disagree with you.  And you have yet to provide any
justification for not thinking it is wise.

|> }  Workstations on Project Athena are private.  One person, one machine (there
|> }are exceptions, but they are just that, exceptions).
|> Oh, you do not support rlogin - ic.
|> So tell me, how do I get at my files from a remote location?

  You log into the dialup hosts.  Which are not "public workstations," and
which do not have a public root password.

|> I feel the authentication is unneccesarily neccesary. You have made
|> it a neccesity by putting power in the users' hands that should not
|> be there. I will not applaud you for making things more difficult.

  Um, how is it more difficult for me to have to type two commands in my
current environment to get write access to the source tree (if I am allowed
that access), while allowing to keep my entire environment, than it would be
for me to have to log into a separate source maintenance account in order to
modify the sources?

  And let's not forget that under the Athena system, there is accountability,
because the changes made to the source tree are made by the user ID of the
user who made them, not by a special source maintenance account.  To achieve
that your way, you've got to have a separate source maintenance account for
every person who's allowed to modify the source tree.

|> Why should I have to use a password every time I execute a command?

  You don't have to do anything of the sort.  And I don't see how you ever got
the idea that you did.  Authenticating to a restricted filesystem is a
one-step operation, and the authentication stays until you revoke it (or until
it expires), just as logging into a special account stays until you log out.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710