Bug 20333
| Summary: | [libpam] ftp login fails on unix password when s/key active but not required | ||
|---|---|---|---|
| Product: | Base System | Reporter: | pscott <pscott> |
| Component: | kern | Assignee: | Dag-Erling Smørgrav <des> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
pscott
2000-08-01 06:40:00 UTC
On Mon, 31 Jul 2000 22:38:01 MST, pscott@the-frontier.org wrote: > If a userid has an s/key, but s/key is not required for login, ftp > should allow a unix password, but it does not; only the s/key password > works. You are correct. However, this appears to be the result of two problems. Firstly, ftpd relies on libpam, for which the pam_skey module doesn't appear to handle the return value of skeyaccess(3) correctly. And secondly, ftpd.c itself appears to make the same mistake. The first problem isn't trivial for me to fix. The second is. :-) The following patch to ftpd.c fixes this for the NOPAM case, but there's still breakage in the libpam skey module. You should be able to apply this patch to ftpd.c and then build ftpd with cd /usr/src/libexec/ftpd make -DNOPAM make install clean Ciao, Sheldon. PS: I run a pretty heavily modified ftpd, so you may need to apply the patch by hand. Certainly, the line numbers for the hunk are bogus. Index: ftpd.c =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/ftpd.c,v retrieving revision 1.64 diff -u -d -r1.64 ftpd.c --- ftpd.c 2000/06/26 05:36:09 1.64 +++ ftpd.c 2000/08/01 12:54:47 @@ -1187,12 +1209,13 @@ if (rval >= 0) goto skip; #endif + rval = strcmp(pw->pw_passwd, crypt(passwd, pw->pw_passwd)); #ifdef SKEY - rval = strcmp(skey_crypt(passwd, pw->pw_passwd, pw, pwok), - pw->pw_passwd); - pwok = 0; -#else - rval = strcmp(crypt(passwd, pw->pw_passwd), pw->pw_passwd); + if (rval) { + rval = strcmp(pw->pw_passwd, + skey_crypt(passwd, pw->pw_passwd, pw, pwok)); + pwok = 0; + } #endif /* The strcmp does not catch null passwords! */ if (*pw->pw_passwd == '\0' || On Tue, 01 Aug 2000 15:21:51 +0200, Sheldon Hearn wrote:
> The following patch to ftpd.c fixes this for the NOPAM case, but there's
> still breakage in the libpam skey module.
Please use the following patch instead.
Ciao,
Sheldon.
Index: ftpd.c
===================================================================
RCS file: /home/ncvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.64
diff -u -d -r1.64 ftpd.c
--- ftpd.c 2000/06/26 05:36:09 1.64
+++ ftpd.c 2000/08/01 13:49:08
@@ -1188,9 +1210,12 @@
goto skip;
#endif
#ifdef SKEY
- rval = strcmp(skey_crypt(passwd, pw->pw_passwd, pw, pwok),
- pw->pw_passwd);
- pwok = 0;
+ if (pwok)
+ rval = strcmp(pw->pw_passwd,
+ crypt(passwd, pw->pw_passwd));
+ if (rval)
+ rval = strcmp(pw->pw_passwd,
+ skey_crypt(passwd, pw->pw_passwd, pw, pwok));
#else
rval = strcmp(crypt(passwd, pw->pw_passwd), pw->pw_passwd);
#endif
@@ -1220,6 +1245,9 @@
return;
}
}
+#ifdef SKEY
+ pwok = 0;
+#endif
login_attempts = 0; /* this time successful */
if (setegid((gid_t)pw->pw_gid) < 0) {
reply(550, "Can't set gid.");
Patch applied; problem solved. Paul A. Scott mailto:pscott@the-frontier.org http://www.the-frontier.org/pscott/ On Tue, 01 Aug 2000 19:40:02 MST, "Paul A. Scott" wrote:
> Patch applied; problem solved.
Just a note to avid PR closers: this PR is not fully addressed. We've
fixed ftpd in HEAD only, and only for the NOPAM case.
We still need to fix libpam for S/Key by teaching it to honour
skeyaccess(3). Once that's done and the changes are merged onto the
RELENG_4 branch, we can close this PR.
Ciao,
Sheldon.
Responsible Changed From-To: freebsd-bugs->sheldonh I'll try to tackle this one when I've read the Linux PAM docs. If anyone else wants to take it before I get to it, please feel free. Responsible Changed From-To: sheldonh->freebsd-bugs I did what I could. Time for someone else to tackle this. Actually, markm might be pursuaded to take a look. Responsible Changed From-To: freebsd-bugs->des Over to PAM maintainer. State Changed From-To: open->suspended Still not fixed. My recommendation is to use OPIE instead. Sorry, but OPIE doesn't seem like an acceptable solution because it replaces the standard system daemons that depend on it. That just ain't right! I don't even use this anymore, but it really bugs me that it's *still* a problem. Is it *still* a problem in 4.x? 5.0? If so, then I'll make the time to have a look at the PAM code. Anyone know what the true status of this is before I embark on this adventure? -- Paul A. Scott mailto:pscott@skycoast.us http://skycoast.us/pscott/ |
