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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
