From mboxrd@z Thu Jan  1 00:00:00 1970
From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Message-ID: <Pine.LNX.4.44.0307281440380.30573-100000@fbsd.cpsc.ucalgary.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [9fans] cron authentication
Date: Mon, 28 Jul 2003 14:47:47 -0600
Topicbox-Message-UUID: 072aa298-eacc-11e9-9e20-41e7f4b1d025

I got asked today to explain how exactly auth servers, factotum and secstore
work together, and I think I did a pretty good job at it, until I was asked
how authentication proxies (such as cron) would work in Plan 9.

My question is, exactly how does Plan 9's cron work? Does it keep a set of
keys for the different users it speaks for?

I can see from the source that cron does the following dance:

	fork()
	...
	become andrey
	call auth_proxy as andrey
		open factotum/rpc
		... normal authentication ...
	run rexec as andrey
	...
	exit()

but where does it get the key to authenticate?


The archives show this old mail from the time when, presumably, factotum was
still in development:

	> [snip] For example, I can have a hostagent
	> running on my terminal that brokers all authentication for my processes,
	> even ones on cpu servers.  However, when making calls out from a cpu
	> server, I still have to trust the owner of that cpu server to be running
	> a system that does what my processes ask it to.  Hence, I'm trusting the
	> host owner making him a super-user of sorts.  However, the sphere of trust
	> can be much more arbitrariy and egocentric and I like that.

	> Cron in such a system becomes much harder.  The cron process has to
	> possess some of  my private keys in order to do it's job.  I could
	> limit its ability by certifying scripts that it runs but that's more
	> work.  However, I think I'm going to bite the bullet and do it.

Does cron possess this set of private keys?

andrey