by Steffen Lei » Tue, 26 Mar 1996 04:00:00
Thanks
Steffen
--
_____________________________________________________
Steffen Leich Universitaet Marburg
http://www.wiwi.uni-marburg.de/perl.exe?scripts/sl.pl
by John C. Fricks » Tue, 26 Mar 1996 04:00:00
If I remember right, I changed two files.Quote:>Hi,
>does anyone have a solution for using the imap-system along with a shadowed
>Linux (1.2.13 / Slackware 3.0)?
imap/ANSI/c-client/LDFLAGS:
-lshadow
imap/ANSI/c-client/os_lnx.h add the following line:
#define crypt pw_encrypt
--
John C. Frickson | http://www.gibbon.com/ | * OS/2 * Linux *
Gibbon Computer Products | ftp://ftp.gibbon.com | PGP Fingerprint:
9864 Palm St. NW | Phone: +1 612 754 6557 | FD743D4E209DFC26
Coon Rapids, MN 55433 | VISA/MasterCard/AmEx | 371905C7B52B36E9
by Mark Crispi » Wed, 03 Apr 1996 04:00:00
Use the "slx" port instead of "lnx".Quote:> Hi,
> does anyone have a solution for using the imap-system along with a shadowed
> Linux (1.2.13 / Slackware 3.0)?
-- Mark --
DoD #0105, R90/6 pilot, FAX: (206) 685-4045 ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.
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
3. Shadow passwords on OSF and UW imapd
4. File & Print Client installation trouble
5. building shadow'ed imapd on linux
8. FS PalmPilot Pro + 2mb IR Upgrade + Softwares
9. Moving UNIX .shadow passwords to Cyrus?
10. days till password expired in /etc/shadow
11. Need pop daemon to work with shadow passwords on linux!!!
12. POP3 with password shadowing