Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!ef1c+ From: ef1c+@andrew.cmu.edu (Esther Filderman) Newsgroups: comp.unix.admin Subject: Re: Project Athena Message-ID: Date: 9 May 91 00:17:12 GMT References: <12049@mentor.cc.purdue.edu> Distribution: na Organization: Computing Systems, Carnegie Mellon, Pittsburgh, PA Lines: 41 In-Reply-To: <12049@mentor.cc.purdue.edu> > Excerpts from netnews.comp.unix.admin: 8-May-91 Project Athena ( was Re: > No.. The Grand Master@sage.cc (15868) > } You asserted that we should not be writing to system source code with our > }own account. I responded by pointing out that, in effect, we are not. We > }simply require separate Kerberos authentication, rather than a completely > }separate login, to get source write access. Now you respond by saying that > }that authentication is wrong, when it is in fact what you implied we should be > }doing in the first place. > } > 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. > Why should I have to use a password every time I execute a command? > (I know, you don't have to for *EVERY* command - yet). What is the > purpose of separate accounts? It is so that you have to enter a > password only once. If not, you could just have open connected terminals > and require a password for any special commands (ls, vi, rm, kill). > No need for accounts. I think you misunderstand Jon's point. If I understand the way Athena works: You don't have to use a password every time, but if you want to to write to a certain area (say, system source files) you must authenticate again, once. Then you have *two* authentication instances, one valid for your "home" area and general use, one for the special security area. However, authentication is separate from login; it can be done at any time with a "log" separate similar ticket-granting process. The Andrew system is considering doing this, too. As part of a development team that uses a small portion of Andrew, and as a former Andrew system administrator, I must whole heartedly agree that this is good extra protection and security. ------------------------------------------------------------- Esther C. Filderman ef1c+@andrew.cmu.edu System Manager Library Automation Mercury Project Carnegie Mellon University They are gardeners and carpenters. They are not tomato men.