From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <953d403b8ad56bd6ec80efa5111a6d28@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] how (not) to use an auth server for authentication (and other factotum tales) In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-sjcenjnvwgrxbyclvtsyvjdogo" Date: Tue, 29 Jul 2003 00:06:38 -0400 Topicbox-Message-UUID: 07deab94-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-sjcenjnvwgrxbyclvtsyvjdogo Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit You got it. Loading p9sk1/2 entries for multiple users into a factotum is not a good idea. --upas-sjcenjnvwgrxbyclvtsyvjdogo Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Jul 28 23:23:32 EDT 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Jul 28 23:23:29 EDT 2003 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 8AE9019AF9; Mon, 28 Jul 2003 23:23:21 -0400 (EDT) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 3985019A6D; Mon, 28 Jul 2003 23:23:17 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 4940819A6C; Mon, 28 Jul 2003 23:22:25 -0400 (EDT) Received: from fbsd.cpsc.ucalgary.ca (fbsd.cpsc.ucalgary.ca [136.159.7.68]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 56AF1199D4 for <9fans@cse.psu.edu>; Mon, 28 Jul 2003 23:22:24 -0400 (EDT) Received: from fbsd.cpsc.ucalgary.ca (localhost.localdomain [127.0.0.1]) by fbsd.cpsc.ucalgary.ca (8.12.8/8.12.8) with ESMTP id h6T3MCeH032011 for <9fans@cse.psu.edu>; Mon, 28 Jul 2003 21:22:12 -0600 Received: from localhost (mirtchov@localhost) by fbsd.cpsc.ucalgary.ca (8.12.8/8.12.8/Submit) with ESMTP id h6T3MC9Q032007 for <9fans@cse.psu.edu>; Mon, 28 Jul 2003 21:22:12 -0600 X-Authentication-Warning: fbsd.cpsc.ucalgary.ca: mirtchov owned process doing -bs From: andrey mirtchovski To: 9fans@cse.psu.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [9fans] how (not) to use an auth server for authentication (and other factotum tales) Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Mon, 28 Jul 2003 21:22:12 -0600 (MDT) X-Spam-Status: No, hits=-0.4 required=5.0 tests=USER_AGENT_PINE,X_AUTH_WARNING version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Plan 9 surprised me today for the first time ever -- I tried to cpu to one of the servers as bootes, and ended up there as andrey! couple of hours and some severe mangling with factotum and secstore I found out the problem: normal setup: node1 has the following entries in ctl (names slightly changed to protect the innocent): proto=p9sk1 dom=outside.cs.bell-labs user=andrey !password=someotherpass proto=p9sk1 dom=ucalgary user=bootes !password=bootespass node2 has the following entries: proto=p9sk1 dom=outside.cs.bell-labs user=andrey !password=someotherpass proto=p9sk1 dom=ucalgary user=bootes !password=bootespass this set-up worked well until I changed the dom= entry from 'ucalgary' to something else. trying to cpu from node2 to node1 made me log in as 'andrey'. I believe the sequence of events is as follows: 1. node2 attempts to authenticate to node1 2. it fails to find a correct dom= entry for it 3. selects the next entry matching the protocol (p9sk1) and tries to authenticate with it 4. because both factotums have the correct entry it just automagically works... here's how it looks with debugging on: 1: start proto=p9any role=client yields phase CNeedProtos: ok 1: read 4093 in phase CNeedProtos yields phase CNeedProtos: phase: protocol phase error: read in state CNeedProtos 1: write 0 in phase CNeedProtos yields phase CNeedProtos: toosmall 2048 1: start proto=p9sk1 role=client dom=outside.cs.bell-labs.com yields phase CHaveChal: ok 1: write 31 in phase CNeedProtos yields phase CHaveProto: ok (if you can't recreate this i'll show you the complete log, together with CRelay: ok and whatnot) ------------- the second issue I have to report is probably a feature, but I'd be very glad if someone can explain it properly: a Plan 9 user logs in to a cpu server with drawterm (sounds like a joke, doesn't it? "a bulgarian walks in a bar carrying a napkin..." :). this user, without starting auth/factotum is able to login to every other machine from the same authentication domain: plan9% cat /mnt/factotum/ctl plan9% cpu -h plan9 plan9% one would expect not to be able to log in anywhere if no keys show up in factotum, or there's no factotum running. cheers, andrey --upas-sjcenjnvwgrxbyclvtsyvjdogo--