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
1) 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