From mboxrd@z Thu Jan 1 00:00:00 1970 From: presotto@plan9.bell-labs.com Message-Id: <200007162254.SAA13583@cse.psu.edu> Date: Sun, 16 Jul 2000 18:54:54 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] allow MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-irnxhrokvyvdtoplnndjomyxiq" Topicbox-Message-UUID: def72b50-eac8-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-irnxhrokvyvdtoplnndjomyxiq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'ld tend to agree with this. Kfs for us is primarily a toy that we use only on a few standalone systems that we'ld never type allow on. All of our other systems are 'file system'-less. Hostowner controls local resources and, as such, is a superuser for that box. To a lesser extent, it can be a superuser to a larger domain since the authentication server will allow some id's to 'speak for' other id's when connecting to resources. I'm currently toying with a complete public key based system that doesn't even have this speaks for relation so that there is no super-user. This arrangement makes a lot of things nicer but makes somethings more awkward. For example, I can have a hostagent running on my terminal that brokers all authentication for my processes, even ones on cpu servers. However, when making calls out from a cpu server, I still have to trust the owner of that cpu server to be running a system that does what my processes ask it to. Hence, I'm trusting the host owner making him a super-user of sorts. However, the sphere of trust can be much more arbitrariy and egocentric and I like that. Cron in such a system becomes much harder. The cron process has to possess some of my private keys in order to do it's job. I could limit its ability by certifying scripts that it runs but that's more work. However, I think I'm going to bite the bullet and do it. I'm much enamoured of Mazieres' SFS. I'ld like to make our authentication mechanism as easy to use. --upas-irnxhrokvyvdtoplnndjomyxiq Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Fri Jul 14 20:45:42 EDT 2000 Received: from cse.psu.edu ([130.203.3.50]) by plan9; Fri Jul 14 20:45:40 EDT 2000 Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id UAA14869; Fri, 14 Jul 2000 20:27:27 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Fri, 14 Jul 2000 20:25:56 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id UAA14817 for 9fans-outgoing; Fri, 14 Jul 2000 20:25:51 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ar.aichi-u.ac.jp (none@ar.aichi-u.ac.jp [202.250.160.40]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id UAA14813 for <9fans@cse.psu.edu>; Fri, 14 Jul 2000 20:25:46 -0400 (EDT) Date: Fri, 14 Jul 2000 20:25:46 -0400 (EDT) From: arisawa@ar.aichi-u.ac.jp To: 9fans@cse.psu.edu Message-ID: <20000714235707.287.qmail@nx.aichi-u.ac.jp> MBOX-Line: From kenji Sat Jul 15 08:57:06 2000 Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3J v130.3) Subject: Re: [9fans] allow Reply-To: Kenji Arisawa References: <200007141418.KAA00244@cse.psu.edu> Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk Hello, Rob Pike said: >Better ideas (short of a superuser) are welcome. and pip@stricca.org: >Maybe the use of smart cards might be a solution. I think it is an illusion that we can protect local file system from someone who can touch keyboard of the machine. Plan9 has a good solution for the terminals that are shared by more than one person. That is, "it is best to purge local file systems." On the other hand, There are terminals that are used and managed by a single person. We need not worry about malicious operations by the owner. I believe kfs is intended for this case. UNIX "root" is a formal administrative account. The account worked well until machines were very expensive. But now every one can have machines that run UNIX; and then, inconvenience and insecureness are left for us. Plan9 introduced "host owner" instead of "root". Both govern the machine. Therefore they are superusers. I think problem with kfs is in that it does not make distinguish between "host owner" and others. "host owner" is, in fact, a special user in terminals and/or servers. Therefore, I think some operations should be limited only to host owner. For example, "disk/kfscmd allow" should allow only to host owner to ignore access permission. Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp --upas-irnxhrokvyvdtoplnndjomyxiq--