[SSSD] [PATCH] Chain authentication requests in all Kerberos-based providers

Simo Sorce ssorce at redhat.com
Fri Jul 3 19:26:47 UTC 2015


On Fri, 2015-07-03 at 20:33 +0200, Jakub Hrozek wrote:
> On Fri, Jul 03, 2015 at 02:12:34PM -0400, Simo Sorce wrote:
> > On Fri, 2015-07-03 at 11:59 +0200, Jakub Hrozek wrote:
> > > On Fri, Jul 03, 2015 at 11:54:46AM +0200, Jakub Hrozek wrote:
> > > > Hi,
> > > > 
> > > > the attached patches fix https://fedorahosted.org/sssd/ticket/2701
> > > > 
> > > > The first patch just adds a common function instead of copying the same
> > > > pattern again to the new test.
> > > > 
> > > > The second adds a new request krb5_auth_queue_send() that wraps
> > > > krb5_auth_send() and also uses the Kerberos authentication queue. I hope
> > > > the unit tests cover a lot of use-cases, if not, please suggest more!
> > > > 
> > > > btw I was thinking that the chaining might not always be necessary if
> > > > the ccache is of type MEMORY and I hope that the serializaton wouldn't
> > > > be perceived as performance regression for users. Shall we say that
> > > > Pavel's cached auth patches are a more systematic solution that doesn't
> > > > rely on properties of the ccache type in that case?
> > > 
> > > I'm sorry, but CI fails on Debian because of wrong linking with
> > > libraries. I'm already testing a fix. Review of the rest is appreciated
> > > :-)
> > 
> > If we are serializing all authentications then a busy server would be
> > swamped. I do not see a per-user/per-cache queue so I would tentatively
> > NACK the approach sorry.
> 
> Thanks for the feedback!
> 
> I had my doubts about serialization by default as well, but I would like
> to note that serialization had been the default in the krb5 responder,
> just not IPA or AD responder since 2010...
> 
> Please note I'm not bashing the existing code, I think the serialization
> is the only good approach for old platforms that use FILE: ccache by
> default..which I guess is why we used it.

I'd have no problems bashing the existing code, it is not perfect, but
we should use this chance to improve it :-)

> > If clobbering is the only issues
> > we have then what we can do is to
> > always use a custom memory ccache for each auth attempt and then use a
> > locking mechanism to copy from the memory ccache to the actual ccache.
> 
> This is an issue on old platforms like RHEL-6 where FILE is the only
> (supported) ccache. So memory cache might not be available..
> 
> For better or worse, these platforms are used in critical environments
> and high-load servers and are hitting the bug.

Afaik the Memory ccache is available in all OSs we support including
very old RHEL versions.

> > 
> > But we should really do either per-ccache queuing
> 
> Can you elaborate a bit? Are you suggesting to use ccache as the key in
> the hash table? I would have to think about a bit, but so far it seems
> like a bit of an overkill, because even now if the same ccache was used
> for different users we would clobber it anyway I think.

Sure, but it is as easy to index it by user name or by ccache, so we can
just go by ccache.

> > (maybe not per user as
> > in pathological cases we may have the same ccache for different users ?)
> > or use memory ccaches and copy them with locking
> 
> Yes, but memory ccache is not available on all platforms..

Which platforms miss it ? I am not aware we support any platform that
lack the MEMORY ccache type, but I may be wrong.

> >, but fully serializing
> > all authentications is not really a solution, when a full auth may
> > require multiple network roundtrips.
> 
> That's why I was suggesting using the cached auth feature as a remedy.

It is not a remedy, if you have a few hundred users logging in, in the
morning, all at once, there is no reason to serialize all their
operations, and serializing them would make some user wait way too much.
Caching wouldn't help as there'd be no cache to check.

> But I do see your point. Would serializing only for FILE: ccache be an
> accebtable option for you? Something like:

No, it would be wrong, DIR or KEYRING ccahes have the same issues IMO.

> def krb5_queue_auth_send()
>     if ccache_type == FILE:
>         queue()
>     else:
>         send_auth()
> 
> Then we could document for admins that on busy servers that are
> unfortunate to only support FILE ccache, use cached auth. If you're
> running on a recent platform (RHEL-7+), though, serialization is
> not used.

Nope, I think per-user serialization (and actually maybe even auth
de-duplication, why not, if user/pw are the same why run the whole stack
twice ?) is what we need in all cases.

Actually in most cases de-duplication would successfully handle 99.9% of
the issues/races. The only case left would be people firing in rapid
succession auth attempts with different parameters (which could still
happen if we think of Optional 2FA logins, but would be much rarer).

Simo.




More information about the sssd-devel mailing list