> > > - plan on using shared secret authentication schemes like PLAIN or > > DIGEST-MD5. expect administrators to use plaintext password databases. > > I bet most administrators would prefer to have an encrypted password file.
As far as I can tell (and the docs are fairly sparse on the ground) the most commonly used mechanisms are PLAIN, CRAM-MD5, and DIGEST-MD5. Unfortunately, from http://www.postfix.org/SASL_README.html#testing_saslauthd: "These mechanisms send credentials encrypted but their verification process requires the password to be available in plaintext. Consequently passwords cannot (!) be stored in encrypted form." Since this is a mechanism-specific issue it is true independent of where the passwords are stored. (The most common locations being sasldb (a Berkeley DB on disk), an LDAP database, or a SQL database. There is a better mechanism out there, SCRAM-SHA-1, but it isn't widely deployed yet. This is short and related: http://prosody.im/doc/plain_or_hashed The examples for e.g. Postfix and memcached typically steer the administrator toward the use of sasldb for the authentication database. Strange, I know. > - build an evented server modelled after beanstalkd, reusing net.c / > > sock-*.c / sd-daemon.* / srv.c and following the patterns of conn.c / > > prot.c. [1] > > Ok, but a great deal of the code in beanstalkd (especially prot.c) is > messy and disorganized. I'm in the process of cleaning it up, bit by bit, > as time permits. > I noticed that. :) Are there any examples of asynchronous servers in C that you've seen which are particularly attractive, from a codebase perspective? (This is the first one I've ever looked at.) > > - modify beanstalkd to have a switch that causes it to listen to a > PF_UNIX > > socket bound to a path. recvmsg() instead of accept(). > > Perfect. You might also want to think about modifying net.c to properly > handle a unix socket inherited from systemd. Cool. Should just be able to patch make_server_socket to check with sd-daemon.c:sd_is_socket_unix, right? > > [2] My first cut of a wire protocol: > > ... > > This looks great. I have a small objection to using the word "auth", > because it's ambiguous (it could be short for "authentication" or > "authorization"). > Fair 'nuff. > Clients that intend to pipeline commands will have to stall until getting > AUTH_OK, and probably won't be able to do much of any pipelining > at all during authentication. I'm not sure if that needs to be explained > as part of the protocol spec. Great point, it definitely should. Especially since depending upon SASL configuration there could be (in theory) arbitrarily many rounds of challenge/response during authentication. Jon -- You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en.
