We *really* need a ccache instance ID tag. In fact, we should probably
never krb5_cc_initialize() a ccache that doesn't have such a tag. But
for now cred_delete() is now safe enough.
If we're racing enough we could complain about symlinks where there were
none. This was very surprising. Make it surprise less.
We should really #ifndef O_NOFOLLOW that code chunk too, for the obvious
reason that we don't need to worry about symlinks if we have and use
O_NOFOLLOW.
Also, since all uses of fcc_open() use O_NOFOLLOW we should move that
into fcc_open(). Ditto O_BINARY and O_CLOEXEC.
st_dev and st_ino are not set in a consistent fashion by stat()
and fstat() so disable the symlink test.
disable the open group/other readable test because st_mode
cannot be used to perform such a test on Windows.
Change-Id: I1b68c672f882018def7e6d40d4bc7f7add58df36
- use O_NOFOLLOW
- be more strict not to follow symlinks
- require cache files to be owned by the user
- have sane permissions (not group/other readable)
Validate krb5_ccache and krb5_cc_cursor inputs
before use. Avoid null pointer dereference which
can occur if an application fails to properly check
return codes.
Change-Id: I8023808936e60cc7b8e57a062106cfcdc51ee7d7
roken/rename.c is for platforms where the native rename()
implementation does not replace the target if it already exists. This
implementation isn't atomic, but should be close enough for most
purposes.
For correct behavior, rk_rename() should be used instead of rename().
rk_rename() is #defined to be rename() on platforms where this fix is
not necessary.
This usually occurs when re-initializing a file credential
cache over the top of an existing one.
This was meant to be fixed in commit 48cb3aa by calling
fcc_destroy(), but that only unlinks the "from" file
(which was already renamed or unlinked) but still doesn't
free the in-memory credentials. Using fcc_close() instead of
fcc_destroy() frees the leaked in-memory credentials.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
Fix resource leak in heimdal/krb5/fcache/fcc_remove_cred
In fcache, fcc_remove_cred generates a ccache called
"newfile," which is not cleaned up if the final call
(krb5_cc_move) fails.
Free of uninitialized value in fcache/fcc_move(...)
If init_fcc fails to acquire a file handle, sp will be
uninitialized. If this is the case, the call to
krb5_storage_free will dereference this uninitialized value,
which causes undefined behaviour.
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@24944 ec53bebd-3082-4978-b11e-865c3cabbd6b
