If you have a SYSV semaphore, you can serialize access to the kcheckpass program. I would suggest generating a unique semaphore key based on the UID of the process and allowing use of the semaphore by processes in the same group (shadow). The idea works like this: - check for semaphore, the key based upon the current process' UID plus a Magic number. - if semaphore exists, wait on it. - once the lock is obtained, perform the query to the shadow file. - if password incorrect, wait n seconds. - release semaphore. The above sequence serializes access to the shadow file, via UID. You'll never have more than one kcheckpass authentication routine running at a time. Additional methods include: Using POSIX semaphores. Shared memory and POSIX mutex locks. MMAP of a file and POSIX mutex locks within. Lockfiles based upon UID. All of these methods can be used to serialize access to the authentication function of kcheckpass. --Perry > > Having spat of my email, I realize that in fact it throughput remains the > same regardless of a delay, assuming no limitation on parallelism. That > is, as long as you can run a large number of processes, a one second delay > does not affect the throughput, only the latency on verification. On the > other hand, there are probably enough ways to attempt to brute force a > password that attempting to limit throughput at any one location makes no > difference. The real answer is probably good passwords and auditing -- > any administrator observing 40,000 incorrect passwords should be > suspicious. > > Robert N Watson > -- Perry Harrington System Software Engineer zelur xuniL () http://www.webcom.com perry.harringtonat_private Think Blue. /\
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:23:53 PDT