k5start -K and ticket renewals

[Russ Allbery]

Nico Williams <nico at cryptonector.com> writes:
> On Tue, Jan 28, 2014 at 5:10 AM,  <moritz.willers at ubs.com> wrote:

>> If the behaviour is changing and k5start refresh the ticket more
>> regularly, then the updating of the CC must always be atomic. If I
>> remember correctly, this is right now only the case if -o, -g or -m are
>> specified.

> As to atomicity... the FILE ccache currently depends on POSIX file
> locking at least for additions of tickets, and this is a disaster
> because POSIX file locking is a disaster (because of its drop locks on
> first close semantics).  But yes, *renewal* and refresh should always
> result in a rename(2) into place, which should be atomic.

By that do you mean that the Kerberos libraries do that, or that I need to
do that in k5start?

I assume krenew is fine (to the extent that POSIX locking is fine).

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>