Skip Menu |
 

History Show all quoted text — Show full headers
# Mon Dec 16 14:33:42 2013 Andrea Campi <andrea.campi@gmail.com> - Ticket created
From: Andrea Campi <andrea.campi@gmail.com>
Date: Sat, 14 Dec 2013 22:06:46 -0800
Subject: krb5_cc_retrieve_cred_seq manipulates KRB5_TC_OPENCLOSE in a non-threadsafe way
To: krb5-bugs@mit.edu
Download (untitled) / with headers
text/plain 448B
Download (untitled) / with headers
text/html 530B
krb5_cc_retrieve_cred_seq changes the OPENCLOSE property not-atomically, i.e. it unsets this property then releases the lock, then sets this property at the end.
In the meantime other threads get a messed up OPENCLOSE state for the cache.

So what's happening is that if another thread tries to read the credentials cache while this OPENCLOSE flag is in the off state, it won't actually open the file for reading (assuming that it's already open).
# Mon Dec 16 15:01:30 2013 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 568B
The OPENCLOSE flag is intended to be a matter of optimization, not
correctness. Another thread using the already-open file shouldn't
generally be a problem; it will just be a little faster. Are you seeing
a more severe issue than this?

(I can think of a scenario where there are two overlapping
krb5_cc_retrieve_cred_seqs running in different threads, and when the
first one finishes, it turns the OPENCLOSE flag back on, causing the
other thread to run less efficiently. But I still don't see that causing
a user-visible problem, just an efficiency issue.)
# Mon Dec 16 18:29:26 2013 Andrea Campi <andrea.campi@gmail.com> - Comments added
From: Andrea Campi <andrea.campi@gmail.com>
Date: Mon, 16 Dec 2013 15:29:05 -0800
Subject: Re: [krbdev.mit.edu #7804] krb5_cc_retrieve_cred_seq manipulates KRB5_TC_OPENCLOSE in a non-threadsafe way
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 877B
Download (untitled) / with headers
text/html 1.3KiB
It's not just efficiency, it can actually cause errors.



On Mon, Dec 16, 2013 at 12:01 PM, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:
Show quoted text
The OPENCLOSE flag is intended to be a matter of optimization, not
correctness.  Another thread using the already-open file shouldn't
generally be a problem; it will just be a little faster.  Are you seeing
a more severe issue than this?

(I can think of a scenario where there are two overlapping
krb5_cc_retrieve_cred_seqs running in different threads, and when the
first one finishes, it turns the OPENCLOSE flag back on, causing the
other thread to run less efficiently.  But I still don't see that causing
a user-visible problem, just an efficiency issue.)

# Mon Dec 16 18:29:26 2013 Andrea Campi <andrea.campi@gmail.com> - Correspondence added
From: Andrea Campi <andrea.campi@gmail.com>
Date: Mon, 16 Dec 2013 15:29:05 -0800
Subject: Re: [krbdev.mit.edu #7804] krb5_cc_retrieve_cred_seq manipulates KRB5_TC_OPENCLOSE in a non-threadsafe way
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 877B
Download (untitled) / with headers
text/html 1.3KiB
It's not just efficiency, it can actually cause errors.



On Mon, Dec 16, 2013 at 12:01 PM, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:
Show quoted text
The OPENCLOSE flag is intended to be a matter of optimization, not
correctness.  Another thread using the already-open file shouldn't
generally be a problem; it will just be a little faster.  Are you seeing
a more severe issue than this?

(I can think of a scenario where there are two overlapping
krb5_cc_retrieve_cred_seqs running in different threads, and when the
first one finishes, it turns the OPENCLOSE flag back on, causing the
other thread to run less efficiently.  But I still don't see that causing
a user-visible problem, just an efficiency issue.)

# Mon Dec 16 20:13:33 2013 ghudson@mit.edu (Greg Hudson) - Subject changed from 'krb5_cc_retrieve_cred_seq manipulates KRB5_TC_OPENCLOSE in a non-threadsafe way' to 'Can't write to file ccache with OPENCLOSE unset'
# Mon Dec 16 20:13:33 2013 ghudson@mit.edu (Greg Hudson) - Status changed from 'new' to 'open'
# Mon Dec 16 20:13:33 2013 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 132B
I see. I'd characterize that as a bug in cc_file.c's handling of the
OPENCLOSE flag. I've updated the ticket subject accordingly.
# Mon Nov 03 13:25:38 2014 ghudson@mit.edu (Greg Hudson) - Given to ghudson@mit.edu (Greg Hudson)
# Mon Nov 03 13:25:38 2014 ghudson@mit.edu (Greg Hudson) - Status changed from 'open' to 'review'
# Mon Nov 03 13:25:38 2014 ghudson@mit.edu (Greg Hudson) - Correspondence added
From: ghudson@mit.edu
Subject: git commit
Download (untitled) / with headers
text/plain 946B

Stop using KRB5_TC_OPENCLOSE

Since KRB5_TC_OPENCLOSE no longer does anything, stop setting it when
we iterate over ccaches.

https://github.com/krb5/krb5/commit/ec3a2e9ea2d4fdb2e00fc7b2a6bfed7feac10880
Author: Greg Hudson <ghudson@mit.edu>
Commit: ec3a2e9ea2d4fdb2e00fc7b2a6bfed7feac10880
Branch: master
src/clients/klist/klist.c | 15 ---------------
src/clients/ksu/main.c | 5 -----
src/lib/gssapi/krb5/acquire_cred.c | 7 ++-----
src/lib/krb5/ccache/cc_retr.c | 14 +-------------
src/lib/krb5/ccache/cccopy.c | 26 --------------------------
src/lib/krb5/krb/vfy_increds.c | 25 +++++--------------------
src/windows/cns/cns.c | 15 +--------------
src/windows/cns/tktlist.c | 11 +----------
src/windows/leash/KrbListTickets.cpp | 4 ++--
src/windows/leashdll/lshfunc.c | 4 ++--
10 files changed, 14 insertions(+), 112 deletions(-)
# Fri Sep 18 12:54:12 2015 tlyu (Taylor Yu) - Status changed from 'review' to 'resolved'
# Fri Sep 18 12:54:12 2015 tlyu (Taylor Yu) - Version_Fixed 1.14 added