On Fri, Oct 15, 2010 at 02:13:05PM +0200, Jan Zelený wrote:
I'm sending a patch which is resolving ticket #533 by implementing a hash table into the PAM responder.
For testing I followed this approach: 0) Configure sssd to use RH LDAP and KRB
- Activate shaping on the host computer
tc qdisc add dev eth0 root netem delay 2s 2) Run 2 separate shells with non-root user logged in 3) In both shells run su - <login> simultaneously 4) When asked for password, type in your password, but don't hit enter 5) When you have a password typed in both shells, hit enter in the first one, quickly switch to the other one and hit enter there (you should have 2s window to do this)
In both shells you should be logged in as <login> and you should have the same ticket cache file.
Something about the concept: I took it from NSS responder (or rather the common part, which retrieves information about user) as suggested in the ticket. But as Jakub pointed out to me, it is questionable whether we want to invoke all associated callbacks by scheduling them on the same time. The easier alternative is to call them all one after another in a cycle. I suppose it was implemented this way so it doesn't take long to forward all associated replies and other requests from PAM module can be served. Am I right? Or would it be better to re-write the patch and use the cycle instead?
Thanks Jan
We have decided to take a different approach to solve #533, see https://fedorahosted.org/sssd/ticket/533#comment:7 for details.
Nevertheless I have two comments: - instead of using tevent_add_timer() with the current time it might make sense to use tevent_schedule_immediate() here - instead of using hash_create() you should use sss_hash_create(), because hash_create() will use malloc() to allocate memory and not talloc
bye, Sumit