9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <Pine.LNX.4.44.0307282045420.31794-100000@fbsd.cpsc.ucalgary.ca> (raw)

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



             reply	other threads:[~2003-07-29  3:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-29  3:22 andrey mirtchovski [this message]
2003-07-29  4:06 ` David Presotto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0307282045420.31794-100000@fbsd.cpsc.ucalgary.ca \
    --to=mirtchov@cpsc.ucalgary.ca \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).