On Tue, Mar 11, 2003 at 11:16:24AM +0100, Andreas Aardal Hanssen wrote:
> Then I understand that you agree that reading from 0 is equally simple.
> Reading from 3 is just a hack that qmail/checkpassword uses, because qmail
> has hijacked 0, 1 and 2 for other purposes. It's the year 2003 now, and I
> don't want the authentication API to expect fd 3 to be free for use.
> The stub bincimap-auth-checkpassword will still write to checkpassword's
It's more than 'just a hack', it allows for checkpassword to be used 'inline' with a
daemon that reads/writes with stdin/stdout to communicate with its clients. A nice
feature when your protocol has clear preauth and postauth behavior.
Binc's authenticator returns after having authenticated but qmail's pop server does
not, its child takes over the pop session on stdin/stdout. For daemons that use
stdin/stdout to communicate with the client, those two handles are not available.
Switching to stdin and abandoning the checkpassword protocol is fine, but doing so
means that we cut ourselves off from every one of the dozens of checkpassword
implementations available right now.
In summary: 1) The functionality we require is completely provided for via the
checkpassword standard. 2) By using the checkpassword format, Binc users can gain
access to many checkpassword implementations that are currently available. 3)
Switching to netstring, and/or fd 0 provides no new functionality. 4) Coding to
support the checkpassword format is no *more* difficult than using fd0.
Therefore, switching gains us nothing real but loses us access to PostgresSQL,
authlib, AFS, NT domain, PHPNuke, PAM, etc. checkpassword programs.
Or an alternate way of saying the same thing: what is so broken about checkpassword
that it is critical enough to warrant creating a *new standard* to fix.
> To the thing about who should be writing authenticators - don't you agree
> that programming experts also let out a "sigh" when they find they have to
> use strange stuff like fd 3? It's just more simple and has no side effects
> to use 0. :D
I think I was trying to make the point that people writing authenticators wouldn't be
letting out a sigh as the fd3 stuff is perfectly ordinary. It's just another IPC
mechanism. Too many application developers get hung up on I/O as being something
other than a bunch of read/write channels, three of which by convention are
unidirectional and have default uses. The remaining (_SC_OPEN_MAX - 3) are *for* file
I/O and communication with child processes. Every unix back to ATT had a system call
to make use of them for this very purpose. It's just the way it's done and the fact
that this program piggybacks along with other programs that already use stdin/stdout
to communicate with clients is all the more reason to steer clear of them.
C=)
--
--------------------------------------------------------------------------
Better the hard truth than the comforting fantasy. -- Carl Sagan
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
A presumption on your part does not constitute an obligation on my part.
