From mboxrd@z Thu Jan 1 00:00:00 1970 From: presotto@plan9.bell-labs.com Message-Id: <200007201211.IAA04506@cse.psu.edu> Date: Thu, 20 Jul 2000 08:10:57 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] auth(6) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-zugenhgrbmkskjlajyoyinblsx" Topicbox-Message-UUID: e72eaf64-eac8-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-zugenhgrbmkskjlajyoyinblsx Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit When machines boot, they need to authenticate to connect to resources such as the file server. Therefore there has to be some user id that the machine authenticates as. Cpu servers authenticate as whatever you typed into the 'authid:' prompt the first time you brought it up (ou can change that later with auth/wrkey). Terminals authenticate as you after you answer the 'user:' and 'password:' prompts. On our systems, all the cpu servers (and the file server as well) authenticate as the same user, 'bootes'. That's just a hack that lets us bring up the auth server 'file system'-less. You don't need to do that if your auth server has its own file system. If a machine is authenticated as X and you want attach to any remote resource from it as user Y, you need hostid=X uid=Y or hostid=X uid=* in /lib/ndb/auth. That pertains to any machine, be it terminal or cpu server. The relation in /lib/ndb auth is, ala Abadi-Lampson, a 'speaks for' relation, i.e., it says that that id X may speak for id Y. Given a request from 'Y', the auth server will return to it a ticket to act as 'X'. The relation hostid=X uid=X is implicit. Therefore, you want to limit who can speak for whom. The relation hostid=X uid=* makes X a super-user of sorts since he can now attach to any resource as anyone. That's the main reason we run servers as 'none', so that someone mounting an attack that subverts the server doesn't gain much more power than the ability to kill other servers. Ideally, we shouldn't even let 'none' debug other 'none' processes since that's a way to learn secrets hidden inside the 'none' server processes. --upas-zugenhgrbmkskjlajyoyinblsx Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Jul 20 05:37:29 EDT 2000 Received: from cse.psu.edu ([130.203.3.50]) by plan9; Thu Jul 20 05:37:27 EDT 2000 Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id FAA02204; Thu, 20 Jul 2000 05:22:37 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Thu, 20 Jul 2000 05:22:28 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA02169 for 9fans-outgoing; Thu, 20 Jul 2000 05:22:24 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA02165 for <9fans@cse.psu.edu>; Thu, 20 Jul 2000 05:22:17 -0400 (EDT) Received: from symnt3.Cadence.COM (symnt3.Cadence.COM [194.32.101.100]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id CAA26246 for <9fans@cse.psu.edu>; Thu, 20 Jul 2000 02:19:41 -0700 (PDT) Received: from pc535-cam (pc535-cam.cadence.com [194.32.97.87]) by symnt3.Cadence.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PHN00HCL; Thu, 20 Jul 2000 10:17:55 +0100 From: "Nigel Roles" To: 9fans@cse.psu.edu Date: Thu, 20 Jul 2000 10:22:07 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: [9fans] auth(6) Reply-to: ngr@9fs.org Message-ID: <3976D2CF.2800.2ED3F73D@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) X-Received: By mailgate.Cadence.COM as CAA26246 at Thu Jul 20 02:19:41 2000 Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk I am intrigued by the /lib/ndb/auth example on auth(6) viz. hostid=bootes uid=!sys uid=!adm uid=* Bootes is typically a fileserver, but I feel this doesn't make sense in this case. Authentication is about convincing a fileserver that a client may speak for a userid, so should I think of bootes as a terminal/cpu server in this context? The long and short is 1. if I want to auth/login on my terminal (T) as user (U) do I need hostid=T uid=U in my /lib/ndb/auth? 2. if I want to cpu(1) from my terminal to my cpu server (C), do I need hostid=C uid=!sys uid=!adm uid=* even if it is also the authentication server? --upas-zugenhgrbmkskjlajyoyinblsx--