From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <a7a62f91c8404185874e1e21c1d659eb@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Authenticated SMTPD or factotum's p9cr
Date: Tue, 21 Aug 2007 07:38:31 +0200
From: lucio@proxima.alt.za
In-Reply-To: <57ac42c5f0899c4d58c066ca7e7f12c4@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: aec47e92-ead2-11e9-9d60-3106f5b1d025

> I can't answer all your questions immediately, but as long as smtpd
> can read the certificate it needs for TLS (typically
> /sys/lib/ssl/smtpd-cert.pem), tcp25 can reside in /rc/bin/service.

Hm, /rc/bin/service/tcp25 runs as "none" and where as it can read the certificate *that's easy), but I could have sworn it could not access the "eve" factotum (I use "proxima" as a replacement for "bootes", I have a feeling there are namespace issues that Bell Labs ought to take into consideration - but that's just a shot in the dark).  I fixed it initially by running factotum within tcp25 and adding the essential keys to it, which improved things, but left me with the "protocol botch".  My problem is that I cannot identify the casue of the botch (factotum's diagnostics - here's me looking a gift horse in the mouth - are no adequate) and that is where everything sticks.  I don't want to mess with the factotum code unless it becomes essential, but I guess it's one route to identify the problem.

> There needs to be a corresponding key in your cpu server(s)'s bootes's
> factotum.  We load ours automatically from bootes's secstore factotum
> file.  It and our ssh server key look like this:
> 
> key proto=rsa service=tls owner=* size=1024 ek=10001 n=[many hex digits] !dk? !p? !q? !kp? !kq? !c2?
> key proto=rsa service=sshserve owner=* size=1024 ek=91 n=[many hex digits] !dk? !p? !q? !kp? !kq? !c2?
> 
The alternative here is:

key proto=rsa service=tls owner=* role=client size=1024 ek=1 n=[...] !dk? !p? !q? !kp? !kq? !c2?
key proto=rsa service=sshserve size=1024 ek=17 n=[...] !dk? !p? !q? !kp? !kq? !c2?
key proto=rsa service=tls role=client size=1024 ek=10001 n=[...] !dk? !p? !q? !kp? !kq? !c2?

Is it possible that the "owner=*" instance is messing up things?  It
is a different entry.  I note, incidentally:

	term% ssh -l proxima huddle
	server huddle not on keyring.
	add key to keyfile (a), continue without adding key (c), or exit (e) [e]c
	ssh: client authentication failed
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

and especially

	term% telnet huddle
	connected to tcp!huddle!telnet on /net/tcp/1
	user: proxima
	authentication failure:auth server protocol botch
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

whereas

	term% cpu -h huddle -u proxima
	huddle# cat 


> Our tcp25 for the outside world ends with this invocation of smtpd:
> 
> exec upas/smtpd -n $3 -gD -m /mail/lib/vfsend.alt -c /sys/lib/ssl/smtpd-cert.pem

I have:

	exec upas/smtpd -d -a -c /sys/lib/tls/virtual.pem -n $3 >[2] /sys/log/smtpd

or, by shuffling the options:

	exec upas/smtpd -n $3 -d -a -c /sys/lib/tls/virtual.pem >[2] /sys/log/smtpd

now I have to understand all the differences, I do presume that "-c"
implies "-a" or that lack of "-a" makes authentication optional.  I
was going to put -gD in later and of course "-d" is temporary (and not
terribly useful, for some reason I need to understand better).

Oh, "-m" is undocumented.  I see it selects a mailer with default
"send" and, yes, "-a" makes authentication mandatory, which is as I
want it.

Thank you for all your help.

++L