On 3 fév, 22:16, Ken Raeburn <[email protected]> wrote: > On Feb 3, 2009, at 14:48, matthieu wrote: > > > I'm currently writing a kerberized daemon and would like to disable > > replay cache. I'm using krb5-1.6.1 (RedHat 5.2). > > > I did not find any relevant function in the API. I finally find the > > krb5_rc_resolve_full function in the krb5 source code and use it for > > now with a replay cache file name like "none:nofile". It works quite > > great. I just have to free the returned krb5_rcache structure manually > > to prevent a memory leak. > > There's an environment variable you can set -- three, actually, though > you only need one here. The library looks for KRB5RCACHETYPE, > KRB5RCACHENAME, and KRB5RCACHEDIR. If you set KRB5RCACHETYPE to > "none" it should disable the cache. >
Tank you, that could be a good solution. The only drawback is that I wrote an API that encapsulate kerberos stuff on TCP stream and that doing it this way it would disable replay cache for all an application, not just scalability concerned parts. > Unfortunately, as you've noticed, the public API doesn't have good > hooks for managing this. > > I recall writing up some notes once about how we might specify replay > caches per service via the config file -- so multiple services using > the same key could be told to use the same non-default cache without > hacking the code or environment for each one in sync -- but after > poking around with google a little I can't find a public record of > it. If you're interested in writing some code to do something like > this, let me know. :-) I will be much better interested, on a short term basis, in a way to do replay cache configuration using the kerberos API. I would rather help you writing this part and let you do the config file one ;) > > > Is there an other way to do that ? The reason why I have to do this is > > that I need to write a scalable deamon and that replay cache mechanism > > provides a huge contention in my multithreaded application. I first > > searched for a way to use a different replay cache file per thread but > > didn't find a way to do it either. > > The problem is, all threads really should be looking at the same data; > sending replay attacks and having them pass undetected because they > were processed by different threads would be poor. Of course, it's > probably still better from a security perspective than completely > disabling the replay cache.... You are right, I came to the same conclusion. Furthermore, as I plan to launch several hundred threads, using numerous replay caches or no replay cache at all would roughly be the same. I saw in the source code that there is a "memory" replay cache type. Is it working ? do you have examples of how to use it ? perhaps the scalability would be better this way without impacting security. > > > I also have an other question. Is it possible to get an addressless > > TGT using a non addressless one. A kind of forward that give you back > > an addressless ticket ? > > Yes, it should be, I think. We don't have any separate programs for > just doing the forwarding and dumping the new TGT into a credentials > cache or anything like that; it tends to be built into programs that > actually send the new credentials. > Thank you, I will take a closer look ASAP and let you know about the results if you are interested in. Matthieu > Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
