From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] identity/ownership Message-ID: <20011107072730.K25942@cackle.proxima.alt.za> References: <20011106153311.5126A199BB@mail.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20011106153311.5126A199BB@mail.cse.psu.edu>; from presotto@closedmind.org on Tue, Nov 06, 2001 at 10:33:08AM -0500 Date: Wed, 7 Nov 2001 07:27:30 +0200 Topicbox-Message-UUID: 17446486-eaca-11e9-9e20-41e7f4b1d025 On Tue, Nov 06, 2001 at 10:33:08AM -0500, presotto@closedmind.org wrote: Got it! :-) > > Define `hostowner' as the id of the user the host is running as, i.e., > the contents of /dev/hostowner. On a terminal the user name and > pawword are prompted for, the user name becoming the hostowner. > On a PC they come from NVRAM, a disk partition called nvram, or > are typed in at boot. Cat /dev/hostowner to be sure. > Settled. I was thoroughly confused for a long, long time. I presume at Bell Labs it is conventional for all CPU servers to have the same owner? I set up the second CPU server specifically for Inferno, so that caused me to have a requirement for two hostids. > Call 'user' the user authenticating from a remote machine. > > If 'hostowner' and 'user' both exist in /mnt/keys on the auth > server with the same keys entered into their respective machines, > then 'user' can successfully authenticate to the cpu and a > process will be started there for him. However, any remote Putting it another way, this is authentication for remote access to the CPU server, right? > resources that process now attaches must be authenticated. > Since the user's key is not on the cpu server, the cpu server > has to speak for the user in the attach. For this to happen > the auth server has to have a 'speaks for' relation in its > /lib/ndb/authid that allows this. > Only later did I pick up the crucial factor, see below. > The 'speaks for' relation in /lib/ndb/authid looks like what you *** you consistently use /lib/ndb/authid, *** but I take it you mean /lib/ndb/auth > said you did: > > hostid=proxima > uid=!sys uid=!adm uid=* > > That means that on a system owned by 'proxima', 'proxima' is allowed > to speak for anyone except sys and adm. If 'user' has > successfully authenticated to the cpu server, the cpu > server should be able to authenticate 'user' in any mount > of a remote file server. Lacking that relation, you will > get attached as 'none'. > I was going to ask about the default, I had overlooked it until right at this moment. > There is an also implicit 'speaks for' relation, i.e., anyone can speak for > themselves. Therefore, you don't need the 'speaks for' relation > > hostid=lucio > uid=lucio > It would seem hard to avoid without a lot of pain and suffering, but it is good to see it spelled out. > That's why you can connect to your terminal whose hostowner is > you and be able to successfully authenticate to remote resources. > > > This all explains your first message but not your most recent. If > > - have added to the /lib/ndb/authid on the filesystem used by the > auth server > This bit I hadn't understood at all. I thought the fileserver, not the authserver, needed the relationship. Why, I'm not sure, but now it all makes a lot of sense. Multiple fileservers are more a pain than a gain, it would seem, I'm interested in opinions on this score, specially if the new fileserver is still going to be released. > hostid=proxima > uid=!sys uid=!adm uid=* > > AND > > - the contents of /dev/hostowner on the cpu server is 'proxima > > AND > > - all the systems use the same auth server > > Then it all should have worked. It does now, after I checked each of the conditions you so nicely presented above, including making sure that the auth server and CPU server agreed on inferno's password. I really appreciate your help, I've been muddled up on this issue for a long time and getting it cleared up was well worth the embarrassment of asking such stupid questions :-) Thanks to forsyth too, for his help. ++L