FILE ccache corruption, possible fix

Greg Hudson ghudson at MIT.EDU
Wed Jan 22 01:12:48 EST 2014

On 01/22/2014 12:57 AM, Nico Williams wrote:
> Oh, of course, readers must delay closing the fildes, or perhaps acquire a
> [whole file] write lock immediately before closing the fildes (to make sure
> not to be stepping on any writer's toes.

I don't think acquiring a write lock just before closing would help; it
wouldn't conflict with a write lock held by another thread in the same
process.  Delaying closing the fd would work, but as far as I know, that
requires basically all of the bookkeeping that the SQLite code does.

Similarly, "don't unlock the ccache when writing, just close" wouldn't
help; all of the process's POSIX locks on the file are dropped when the
fd is closed.

> Boy, it'd be nice if O_APPEND was reliable, but it's not.

I assume you mean it's only reliable up to PIPE_BUF bytes?  It might be
good enough for you in practice.  I would be fine with making MIT's file
ccache code marshal creds to memory and write() them out all at once
with O_APPEND (like Heimdal does), although it would be too big of a
change to backport.  I think it would let us share the marshalling code
between cc_file.c and cc_keyring.c.

More information about the krbdev mailing list