Kerberos kinit handling w.r.t atomicity

Srivatsan vn srivatsan.vn at gmail.com
Mon Jul 1 20:35:40 EDT 2013


Hi Carson/Bense,
                           Thanks for your response, I did some test runs
and the problem is not seen after renaming of the cache file instead of
updating the live cache file. But  Looking at the strace/truss output w.r.t
file open calls, the whole operation does not seem to be atomic.

 The cache file in my case is handled by the following two external process
1. one is kinit or k5start that writes the tgt ticket
2. and the other one is my application which uses Oracle OCI driver that
read/writes the service ticket.

as I understand, doing a rename of cache only makes the TGT ticket
generation process as atomi and not the process that issues the service
ticket.  I guess the cause of this is probably oracle oci open calls does
not open the files in atomic way?

kinit
open("cache1", O_RDONLY) = 4
open("cache1", O_RDWR|O_NONBLOCK) = 4
open("cache1", O_RDWR) = 4

k5start
open("cache1",O_RDWR|O_CREAT|O_EXCL|O_TRUNC, 000)= 3
open("cache1", O_RDWR) = 3

Oracle OCI code using the cache file read
open("cache1", O_RDONLY) = 9
open("cache1", O_RDONLY) = 9
open("cache1", O_RDONLY) = 9
open("cache1", O_RDONLY) = 9

This is probably a very scenario I might encounter in my application env,
and I can always fallback on the error handling, but just wanted to hear
your thoughts.

Thanks,
Srivatsan Nallazhagappan

On Thursday, June 27, 2013 1:01:40 PM UTC-4, Carson Gaspar wrote:
>
>
> kinit into a different credential cache.
> rename the new cache over the old one.
>
> --
> Carson
>


---------- Forwarded message ----------
From: Booker Bense
<bbense at gmail.com<https://xnet.infosys.com/owa/redir.aspx?C=ZuzgF6-LHEamZh-0AqqaLFIhL9dFStAI9iefED22MaUciDo-ROowOOBbi0UgZKQax2MFIn7XhGs.&URL=mailto%3abbense%40gmail.com>
>
Date: Thu, Jun 27, 2013 at 2:31 PM
Subject: Re: Kerberos kinit handling w.r.t atomicity
To: Srivatsan vn
<srivatsan.vn at gmail.com<https://xnet.infosys.com/owa/redir.aspx?C=ZuzgF6-LHEamZh-0AqqaLFIhL9dFStAI9iefED22MaUciDo-ROowOOBbi0UgZKQax2MFIn7XhGs.&URL=mailto%3asrivatsan.vn%40gmail.com>
>


I would give each process it's own separate kerberos cache
file(KRB5CCNAME). You should also look into the kstart program that was
created for just this kind of use.

---------- Forwarded message ----------
From: Srivatsan vn
<srivatsan.vn at gmail.com<https://xnet.infosys.com/owa/redir.aspx?C=ZuzgF6-LHEamZh-0AqqaLFIhL9dFStAI9iefED22MaUciDo-ROowOOBbi0UgZKQax2MFIn7XhGs.&URL=mailto%3asrivatsan.vn%40gmail.com>
>
Date: Thu, Jun 27, 2013 at 10:10 AM
Subject: Kerberos kinit handling w.r.t atomicity
To: kerberos at mit.edu<https://xnet.infosys.com/owa/redir.aspx?C=ZuzgF6-LHEamZh-0AqqaLFIhL9dFStAI9iefED22MaUciDo-ROowOOBbi0UgZKQax2MFIn7XhGs.&URL=mailto%3akerberos%40mit.edu>


Hi Team,

             Can you please provide some insight on how to make kinit as an
atomic operation to deal with concurrency issues. In my application env, I
will have the  periodic kinit job that runs every 8 hours to refresh the
TGT tickets, and I will also have applications that would make kerberised
oracle db connections round the clock.

I tested running the kinit job and my applications running in parallel and
find that the connections fail due to cache credential error. This makes me
think that kinit is not atomic, can you please suggest possible solutions
to this concurrency issue?

When I googled, I could see some generalized solutions listed below .

1) Have a retry logic in the application to make db connections. I can't do
this as I dont have the source code.

2) Explore unix Advisory/Mandatory locking features that could set some
properties on the cache file which would make sure that the cache file is
always locked when its opened by any process. I have to explore if its
supported in my app env as I see its highly related to the type of mounted
filesystem and the operating system. I use Solaris / Linux.

3) Run the kinit during off-peak hours

Please let me know your thoughts.

Thanks,
Srivatsan Nallazhagappan


More information about the Kerberos mailing list