From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9bc085a2c64521b6622e7f23ffcd5358@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] ATA next In-Reply-To: <20040122203626.F28365@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 22 Jan 2004 14:53:15 -0500 Topicbox-Message-UUID: bf0c4bbe-eacc-11e9-9e20-41e7f4b1d025 > 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 Looks like sources doesn't reflect what we do here. We moved that cruft out of /rc/bin/service.auth a while ago. It used to be in service.auth because it needed to get at the TLS private key. We fixed that. I'll fix sources. > (b) does imap4d not need to be able to "speak for" the new user, > which is easiest achieved on an auth server? It's easiest achieved by the user login in which just goes via factotum. Factotum talks to the auth server but it doesn't matter whether the auth server is local or remote.