[Pkg-shadow-devel] passwd behavior

[Alexander Gattin]

Hi!

On Thu, Apr 06, 2006 at 12:08:13AM +0200, Nicolas François wrote:
> I'm thinking of two implementations:
>  * If password do not block any signal
>    execute passwd in a loop and send the signal (KILL if needed) after
>    waiting a little bit (I don't think it is possible not to wait at least
>    a "little bit", this "little bit" will be difficult to define).

Well, I agree -- even in case when you can strace or
debug/profile `passwd` executable, you must have some
timeout when waiting for pam_authenticate() to return.

>  * If password do block every signal (and it is not possible to kill it)
>    Use 1000 threads to execute multiple passwd instances (and wait for the
>    passwd delay, without sending any signals)
> 
> I don't think the first solution will provide a good passwd/s ratio.

Well, I think smth. like 100 passwords/s can be
expected, depending on max system load and therefore
its responsiveness. (Scheduling interval on Linux ==
1/1024s AFAIR. I saw more than 8ms latency with
userspace packet generator BTW.)

But you forgot 3rd implementation, combining both 1st
and 2nd approach. If delay time is considerably larger
than 1s or is exponential [backoff], ;) 3rd approach
can be considerably faster than 2nd.

> Do you think the second implementation is slower than the first one or
> irrealistic (could be blocked by ulimits?)?

Usually ulimits allow 1024 nproc, IIRC. But
theoretically this can be restricted by other means.
Even to the point of allowing to run no more than 1
instance of `passwd` per user. :)

> If not, then I think there is no need to block any signals.

Well, then there's not much difference with `su` or
suid root `login`... (*) We should have consistent
policy WRT signal blocking throughout all shadow suite.

(*) except pam session

-- 
WBR,
xrgtn