[9fans] how (not) to use an auth server for authentication (and other factotum tales)

[9fans] how (not) to use an auth server for authentication (and other factotum tales)

[andrey mirtchovski]

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

Re: [9fans] how (not) to use an auth server for authentication (and other factotum tales)

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 92 bytes --]

You got it.  Loading p9sk1/2 entries for multiple users into a factotum is not a
good idea.

[-- Attachment #2: Type: message/rfc822, Size: 4481 bytes --]

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: [9fans] how (not) to use an auth server for authentication (and other factotum tales)
Date: Mon, 28 Jul 2003 21:22:12 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0307282045420.31794-100000@fbsd.cpsc.ucalgary.ca>

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