FILE ccache corruption, possible fix
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