delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/08/03/04:07:48

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Sun, 3 Aug 2003 01:07:38 -0700
Subject: Re: imapd: authentication problems on imapd-2002d
Mime-Version: 1.0 (Apple Message framework v552)
From: Kevin Camera <kcamera AT kevshouse DOT homeip DOT net>
To: Cygwin List <cygwin AT cygwin DOT com>
In-Reply-To: <001901c358ab$33863070$5400a8c0@xppro8200>
Message-Id: <8C5A8C52-C589-11D7-A486-000A957CBE36@kevshouse.homeip.net>

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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019