This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: imapd: authentication problems on imapd-2002d
- From: Kevin Camera <kcamera at kevshouse dot homeip dot net>
- To: Cygwin List <cygwin at cygwin dot com>
- Date: Sun, 3 Aug 2003 03:28:33 -0700
- Subject: Re: imapd: authentication problems on imapd-2002d
OK, I've fixed CRAM-MD5 authentication as well, using an almost
identical fix as for plaintext, but in another area of the code. For
MD5 authentication, the actual call to authenticate starts in
auth_md5_server() in src/c-client/auth_md5.c. If the
challenge/response hashing function succeeds using the password value
stored in /etc/cram-md5.pwd, the session username is set to the correct
string, otherwise to NIL. At this point, the user's password has been
verified, and the "cyg_user" string must be set to appease the actual
credential-setting code in loginpw() -- see src/osdep/unix/log_cyg.c.
Here is a patch for what I did:
--- auth_md5.c.orig 2003-08-03 03:13:08.000000000 -0700
+++ auth_md5.c 2003-08-03 03:06:34.000000000 -0700
@@ -136,4 +136,5 @@
static int md5try = 3;
+extern char *cyg_user;
char *auth_md5_server (authresponse_t responder,int argc,char *argv[])
{
@@ -155,4 +156,5 @@
pl = strlen (p);
u = (md5try && strcmp (hash,hmac_md5 (chal,cl,p,pl))) ? NIL :
user;
+ cyg_user = (u == NIL) ? NIL : cpystr(user);
memset (p,0,pl); /* erase sensitive information */
fs_give ((void **) &p); /* flush erased password */
Again, this is no more than duct tape. After seeing how this fix
works, it seems like there may not be a much better choice in the short
run, unless someone wants to reorganize the structure of the valpwd()
and checkpw() code, and decouple the dependence of cyg_user from those
functions. I guess it does make sense that there is a static global
variable for storing the authenticated user state, since the
authentication code lies in several places. Perhaps it's just an
awkward choice that this global variable is declared in the checkpw()
source file (src/osdep/unix/ckp_cyg.c), since that is one specific
choice out of several authentication modes.
Anyway, I'd love to hear from some of the maintainers on what they
think the best choice is. But for now, I have a beautifully running
IMAP daemon, and I even tweaked my Exim configuration to read the
/etc/cram-md5.pwd file as well, so I have a single user database just
for mail. Works for me!
Thanks,
Kevin
On Sunday, August 3, 2003, at 01:07 AM, Kevin Camera wrote:
Hi Abe et. al.,
An update on my IMAP problems. I've done some heavy debugging and
fixed one problem, with one more to go.
It turned out the reason my encrypted plaintext logins were failing
was due to some code in the server_login() function in
src/osdep/unix/env_unix.c. I am using the /etc/cram-md5.pwd file to
store my imapd passwords, and in this case some custom code is invoked
which does not properly set the cyg_user static string, as required by
the loginpw() function in src/osdep/unix/log_cyg.c. Here is a patch
which got logins to work for me:
--- env_unix.c.orig 2003-08-01 20:19:53.000000000 -0700
+++ env_unix.c 2003-08-01 20:27:01.000000000 -0700
@@ -521,4 +521,5 @@
*/
+extern char *cyg_user;
long server_login (char *user,char *pwd,char *authuser,int argc,char
*argv[])
{
@@ -541,4 +542,5 @@
if (!strcmp (s,pwd) || ((*pwd == ' ') && !strcmp (s,pwd+1)))
pw = pwuser (user); /* CRAM-MD5 authentication validated */
+ cyg_user = cpystr(user); /* set the matched user as in valpwd
*/
memset (s,0,strlen (s)); /* erase sensitive information */
fs_give ((void **) &s);
In English, I declare cyg_user as an external string pointer (it's
locally declared in ckp_cyg.c) and manually set it to a copy of the
validated user string (this is essentially what happens inside
checkpw() on traditional authentication). This is absolutely a
duct-tape code fix, but I at least included it to show you how I got
it to work. I think the more robust solution is to call the valpwd()
function properly when using cram-md5.pwd data, instead of a pure
manual method. But I will leave the final decision to a more
"professional" programmer :).
However, now that I got authentication to work for plaintext logins
using cram-md5.pwd, I'm finding that using the CRAM-MD5 method itself
still does not work. There is a different call trace for this method
(naturally), and am still debugging this case to find the fault.
Anyway, hope this helps, and I'll be posting soon with my rough fix
for CRAM-MD5, assuming I can find it.
Thanks,
Kevin
On Friday, August 1, 2003, at 09:04 PM, Abe Backus wrote:
Kevin,
I removed the sections of the README that have to do with modifying
/etc/passwd because from what I've seen, the latest imapd (or maybe
it's the
latest cygwin?) is able to authenticate properly without having your
password encrypted in /etc/passwd.
I haven't tried the cram-md5 stuff, so I can't really guess whether
anything
changed there, although the code has changed quite a bit from 2000a to
2002d.
A few months ago, I encountered a windows permissions issue that
prevented
my inetd service from working properly. Check your NT Event Log for
messages from uw-imapd or inetd. Mine said something about "Socket
Operation on Non Socket". I don't get these anymore with 1.5.x
cygwin :)
-Abe
-----Original Message-----
1) The README.cygwin needs to be updated in the 2002d Cygwin package.
It leaves out the bullet which states that "Everyone" and "SYSTEM"
must
be added to the /etc/passwd file. This statement was previously
included in the Sourceforge port, but seems to have been taken out.
My
vanilla Cygwin install had the SYSTEM account at UID 18, but Everyone
at UID 0 had to be added manually. If it's not a security issue,
maybe
that could be added to the base install, or fixed with a postinstall
script. The uw-imapd doc even states that the README.cygwin was taken
from the Sourceforge port, which really threw me off since I never
thought to look back at the port docs...
2) When I compile the Sourceforge 2000a code from source, I get a
server which works perfectly, except the SSL certificate chain is not
followed properly. I can initiate a TLS session, but imapd does not
use my trust chain. I did properly link /usr/ssl/certs/uw-imapd.pem
to
the file /usr/ssl/certs/chain.pem, which contains my private key,
public key, and intermediate trust key, all in that order. I know
this
is no longer the version supported by Cygwin, but I thought I'd
mention
it anyway for others out there.
3) When I install the latest Cygwin package, 2002d-1, I get a server
which will launch fine, traverses my certificate chain fine (the
intermediate authority I appended to the PEM file is found and used),
but will not authenticate anyone! I tried all different types of
authentication (unencrypted plain, encrypted plain, and CRAM-MD5), but
the service just doesn't accept my password. I know that my
/etc/cram-md5.pwd file is OK, since it worked with the 2000a version,
unless the code base for using that file has changed since then. I
have tried all the obvious stuff -- making sure the file is mode 400
and owned by SYSTEM:None, making sure it has UNIX newlines, making
sure
the users are mirrored in /etc/passwd -- but nothing will get imapd to
accept the password.
I am running the daemon in both cases with inetd, which is running as
a
service on Windows 2000. If anyone has any ideas on what could be
causing the logins to fail on the latest version, I would be forever
grateful. It's the only thing left not working after days of trying.
Thanks!
Kevin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/