Commit ad7e54d698 introduced the use
of _krb5_expand_path_tokens() to expand tokens (and on Windows convert
path delimiters) within credential cache names. This is safe to do
for the path based credential cache types FILE, DIR and SCC but on
Windows is unsafe for the non-path types.
For example on Windows, the API credential cache names are often based
on the principal name and the principal name is parsed from the ccname.
This practice was introduced with the version v2 ccapi when there was
no method of enumerating the caches from the krb5 library.
This change adds a "filepath" boolean parameter to _krb5_expand_path_tokens()
which is set to TRUE (non-zero) when the input is a file path and FALSE
(zero) when the input is not a file path. _krb5_expand_path_tokens() will
only perform directory separator normalization on Windows when the
"filepath" parameter is TRUE.
This change is not the preferred solution because it requires that the
library be aware of all credential cache types that use path based
residuals. The preferred solution would require that the credential cache
implementation indicate whether or not it uses a path based residual.
This change has been implemented using a prefix test and not a change to
struct krb5_cc_ops because existing ccache plugins will not know how to
advertise their use of path based residuals and that path expansion is
safe.
Change-Id: I8135991e8ce69fc5273d381ea9c2078bc2bcd19a
The problem is that fcc_get_cache_next() is called in a context where
context->default_cc_name is not set. We should call
krb5_cc_default_name(), and that fixes the problem. There's a comment
warning that this can result in reentering krb5_cc_cache_match(), but
nothing in libkrb5 calls krb5_cc_cache_match(), so the comment is wrong,
at least in the github tree.
An alternative would be to call krb5_cc_set_default_name(NULL) in
kuser/kinit.c before calling krb5_cc_cache_match(), however, that seems
like an insufficiently general solution. Also, the semantics of
krb5_cc_cache_match() would differ from MIT's -- it seems better to
match MIT's semantics.
Programs like sshd may create or access a ccache with
ruid != user's UID, euid == user's UID.
Set-uid-0 programs (ob reminder: they start life as ruid == user's UID,
euid == 0) shouldn't unintentionally access ccaches. Therefore we
shouldn't check both of ruid and euid, just euid.
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
