OTP feature for /bin/login

[Michael Conrad]

On 5/8/2012 9:40 AM, Laurent Bercot wrote:
>> May be PAM is the de facto standard, but what about those whose do not
>> like to use PAM on there systems (as they consider them bloated)?
>   Then we need a lightweight PAM replacement. I've managed to avoid
> thinking about it too much so far, but if people want to add different
> auth mechanisms to busybox, this is the way to go.
>
>   What rubs me the wrong way with PAM is that it requires dynamic
> linking, since it relies on .so and dlopen() mechanisms. There's no way
> to have a complete PAM-enabled system with statically linked binaries.
>
>   With the little amount of thought I've done on it so far, I've concluded
> that a viable system would have to have executables instead of shared
> objects as atoms, i.e. the /bin/login program configurably executes into
> /bin/login-X-mechanism, where X can be passwd, OTP or anything of the
> kind, and /bin/login-X-mechanism does the X-specific work.
>

+1

Call them "Busybox Auth Helpers" and the API is as simple as read 
"$username\n$password\n" from stdin, and return 0 or 1.  Serves 
everyone's needs in about 20 lines of code added to busybox.  All 
configuration and selection of which accounts are affected can be 
written into a Multiplexor which obeys the same API.  You could even 
write an auth helper that dynamically links out to PAM.

It could be as simple as checking getenv("BUSYBOX_AUTH_HELPER"), or 
hard-coded busybox config string.  If it doens't exist, fall back to 
passwd/shadow.

On 5/8/2012 4:22 PM, Guylhem wrote:
> IMHO it follows the spirit of busybox, so the current implementation
> was submitted since already covers most of the needs as it.

Writing a minimal implementation of OTP **as an applet** would certainly 
be in the spirit of busybox.  Adding extra feature-specific behavior to 
existing applets IMHO is not.

-Mike