Nico Williams <n...@cryptonector.com> writes: > On Tue, Jan 28, 2014 at 5:10 AM, <moritz.will...@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 (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
