1. uw imapd bug in checkpw() with shadow passwords (?)
Hi,
my setup:
- latest and greatest imap-2002d tarball
- slackware linux 9.0 using kernel 2.4.18 with shadow passwords
- imapd compiled with SSLTYPE=unix (to have plaintext auth with and without
SSL for testing)
Problem: Login with command
LOGIN watz watzpassword
always got rejected.
User "watz" was able to log in into the system with the above info just
fine.
His /etc/shadow entry looked like this:
watz:ShAdOwPAsS:0:0:99999:7:::0
Using gdb I could verify that c-client rejected the login in checkpw()
because
sp->sp_lstchg
was zero. This is obviously based on the idea expressed in the comment a few
lines above that code:
"lstchg last password change date if non-negative. If zero, the user can
not log in without changing password."
However I was able to log in just fine with this user, no password change
needed. The user was created with the slackware admin tool on installation,
this is why the lastchange field is empty (its the initial pass and it has
never been changed and theres not really a need to because it was created
manually).
For testing I let this user change the password to something else, shadow
entry looked like this then:
watz:ShAdOwPAsS::12232:0:99999:7:::0
Now imapd would accept the LOGIN command above.
It may not actually be an imapd bug...but obviously the linux login behaves
different compared to the imapd login here. Linux login lets me in with no
password change needed anc c-lient locks me out.
It was a pretty confusing thing though since I never had troubles with the
plaintext LOGIN. This behaviour may be very confusing to other people also
since theres no obvious reason why imapd rejects the login.
If no action in c-client will be done I would suggest this behaviour gets at
least documented somewhere in the imapd FAQ.
Also...it would be nice to have some /var/log/mail lines dropped with a
reason why the passwords were rejected. Hmm although it might be readable
by ordinary users. Isn't there a way to have some diagnostic information
dropped somewhere without creating a security risk ?
Maybe some imapd command line option that would, if explicitely supplied
i.e. in inetd.conf, drop diagnostic info to /var/log/mail etc. ?
This would be extremely handy in situations like this.
Greetings,
Watz
2. Hardware and Operating System Choice?
3. Imapd and shadow-passwords
4. comp.compilers monthly message and Frequently Asked Questions
5. UW IMAP make parameter for Red Hat Linux 7 with Shadow password and MD5
6. proc calis
7. pop client in uw-imapd.. the password?
8. Dark Queen of Krynn help needed
9. building shadow'ed imapd on linux
10. imapd and shadow passwd
11. Moving UNIX .shadow passwords to Cyrus?
12. days till password expired in /etc/shadow
13. Need pop daemon to work with shadow passwords on linux!!!
by