Hi Stuart,
Thanks for your consideration. I'm aware about the FileDataSource issues, we have
some performance/load tests to help identify such issues. As we have rewritten the stores,
one of my tasks is run this tests to identify and solve such issues.
Regarding the date format, the timezone does not change.
Thanks.
----- Original Message -----
From: "Stuart Douglas" <sdouglas(a)redhat.com>
To: security-dev(a)lists.jboss.org
Sent: Tuesday, August 6, 2013 4:02:26 AM
Subject: [security-dev] Picketlink thread safety issues
Hi,
I have just been looking over Picketlink and I think I have spotted a couple of thread
safety issues:
- File Data Store is not thread safe
It looks like there are quite a few problems here, but the biggest is that FileDataStore
does not seem to use any sync, so multiple threads can be attempting to write out the
database at the same time. Also threads can be modifying the database in memory at the
same time it is being written out, so it is possible to write the DB in an inconsistent
state.
Also when the file is written out it is written out directly over the old file, which
greatly increases the chance of file corruption (rather than writing a tmp file and then
moving it over the existing one). The also means that any sort of error (such as a
non-serializable attribute) will corrupt the store and make it unreadable.
- LDAPIdentityStore is using SimpleDateFormat in a non-threadsafe manner
LDAPIdentityStore uses a static SimpleDateFormat, which is not thread safe. Not only that
but this date format is modified before it is used in LDAPIdentityStore#parseLDAPDate, so
if multiple threads are parsing dates with different timezone formats at the same time
anything could happen.
Stuart
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev