On Wed, 2005-10-19 at 15:21 +0100, pod@herald.ox.ac.uk wrote:
"TS" == Timo Sirainen tss@iki.fi writes:
TS> In any case login/master processes wouldn't have to know anything TS> about GSSAPI there, they'd just forward parameters from TS> dovecot-auth blindly (I think master already does?).I'm not sure it does. I've tried handing back gssapi_qop, gssapi_max_size and gssapi_context as extra fields but I've not obviously seen those fields available in the imap process.
Hmm. If userdb returns unknown fields, they are just put to environment variables. That's why setting "quota" in userdb reply reaches the quota plugin even though nothing in Dovecot's code knows about it.
TS> plus side there is that if there happens to be any exploitable TS> security holes in GSSAPI library, login process would be running TS> in chroot and attacker wouldn't get direct access to anyone's TS> mails.Couldn't this be a downside also? The login process would hold the user credentials but is running as the same user as all the other imap-login/proxy processes - if there were a way to get at the process address space of the other processes one could steal the credentials. I can't decide if this is just a theoretical possibility or a credible risk.
Those processes are treated as setuid-processes by kernel, so they can't touch eachothers unless there is some kernel bug.. AFAIK the only thing they could be able to do to eachothers is to send signals.