From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] ATA next Message-ID: <20040122203626.F28365@cackle.proxima.alt.za> References: <20040122162315.D28365@cackle.proxima.alt.za> <25ce826aaa31b7b821046e74fd4c681b@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <25ce826aaa31b7b821046e74fd4c681b@plan9.bell-labs.com>; from David Presotto on Thu, Jan 22, 2004 at 10:53:26AM -0500 Date: Thu, 22 Jan 2004 20:36:27 +0200 Topicbox-Message-UUID: be6ffa3e-eacc-11e9-9e20-41e7f4b1d025 On Thu, Jan 22, 2004 at 10:53:26AM -0500, David Presotto wrote: > > There's no reason why imapd should run on an auth server. > Lots of services change id (cpu, rx, ssh, ...). > Please pardon me, I'm being lazy, now. What I could probably figure out by reading enough man pages and code is (a) why then the TLS imap4d service is in /rc/bin/service.auth, implying that as a trusted service it ought to run only on an auth service (there's a clear indication that that is expected in the cpurc text) and (b) does imap4d not need to be able to "speak for" the new user, which is easiest achieved on an auth server? Assume I still don't quite grasp all the complexities of Plan 9 authentication, it is just too subtle. I have checked what I thought was pertinent, but I kept missing something indefinite. Lastly, and again I assume I could figure this by myself, but a superficial search led me to believe that there's someone out there who can explain it a little better, what are the preconditions for imap4d to operate correctly under TLS? According to the documentation the certificate is generated on the fly by /rc/bin/service.auth/tcp993, but I'm not altogether convinced :-( The directory /sys/lib/ssl in which a cert may be stored certainly did not exist before I created it. It has remained empty since :-( Thanks to anyone who can shed some light on this. ++L