Date: Fri, 7 Dec 2001 16:35:49 +0200 From: Ruslan Ermilov <ru@FreeBSD.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Peter Wemm <peter@FreeBSD.org>, Mark Murray <markm@FreeBSD.org>, Bruce Evans <bde@FreeBSD.org> Subject: Re: PAM, libssh, and all that (was: Re: cvs commit: src/lib/libpam/modules/pam_ssh pam_ssh.c) Message-ID: <20011207163549.E65808@sunbay.com> In-Reply-To: <xzpu1v315kv.fsf@flood.ping.uio.no> References: <200112071151.fB7BplS52145@freefall.freebsd.org> <20011207155257.A65808@sunbay.com> <xzpy9kf167h.fsf@flood.ping.uio.no> <20011207160554.C65808@sunbay.com> <xzpu1v315kv.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 07, 2001 at 03:13:20PM +0100, Dag-Erling Smorgrav wrote: > Ruslan Ermilov <ru@FreeBSD.org> writes: > > On Fri, Dec 07, 2001 at 02:59:46PM +0100, Dag-Erling Smorgrav wrote: > > > Ruslan Ermilov <ru@FreeBSD.org> writes: > > > > On Fri, Dec 07, 2001 at 03:51:47AM -0800, Dag-Erling Smorgrav wrote: > > > > > Log: > > > > > Get pam_mod_misc.h from .CURDIR rather than .OBJDIR or /usr/include. > > > > Um, why?! > > > Because that's the way the other modules do it, and in some > > > circumstances, pam_ssh won't build at all without this change. > > Look, I asked "why". Please tell us your fellow developers why > > this was needed. I fail to see the reason myself. Is it so hard? > > When building libpam separately (not as part of a world build), > pam_ssh will incorrectly use the copy of pam_mod_misc.h from > /usr/include instead of the one from the source tree. Since you have > to build the modules before the library (because they're linked into > the static library), if you introduce a non-backward-compatible change > in pam_mod_misc.h or nuke /usr/include/security before building, > pam_ssh won't build. All the other modules get this right by > including "pam_mod_misc.h" instead of <security/pam_mod_misc.h>. > This is not true that all the other modules do this. These modules include pam_mod_misc.h correctly: pam_ftp/pam_ftp.c pam_rootok/pam_rootok.c pam_securetty/pam_securetty.c pam_self/pam_self.c pam_wheel/pam_wheel.c All the modules that do include it "", do this wrong. This is not the way we solve bootstrapping issues. Bootstrapping issues are solved by properly maintaining the bootstrapping environment, that's why we recommend a "full make world" when we introduce an incompatible change in headers. Also, imagine a situation when you add a new /usr/include header. If you build your program for the first time, /usr/include won't have that header, but that's not a valid reason to include it "". More importantly, including headers "" may be bogus when doing a cross-platform builds, if there are multiple copies of the same MD header exist. You should only include a header "" if it's not installable into /usr/include. Otherwise, you should include it <>. It's a responsibility of "upgrade procedure" to install up-to-date headers, and use them at build time, and we already do this right with "make world" -- our standard upgrade procedure. I've done a large job recently cleaning up all /usr/src Makefiles that used to have -I pointing back to ../sys/* headers. If you want to test your (incompatible) modifications to a header file, you can use DEBUG_FLAGS (for bsd.prog.mk and bsd.lib.mk equipped makefiles), to add the necessary -I glue to CFLAGS. > An alternative fix would be to repocopy pam_mod_misc.h into > src/lib/libpam/libpam/security and fix the Makefiles accordingly; all > modules could then #include <security/pam_mod_misc.h> and get the > right version of pam_mod_misc.h. This was my initial intention, but > cvs@ asked me to change pam_ssh.c instead. > Nope, this is not the right thing to do either. The right thing to do (if you introduce a backward incompatible change to a header, or implement a new feature) is to upgrade your /usr/include first, or manually point (with DEBUG_FLAGS) your make(1) to use up-to-date headers. Otherwise, why do we have /usr/include at all? :-) > > > > On a side note, with recent pam.d changes, something is seriously > > > > screwed. I don't have USE_PAM_D setting in my make.conf(5), and > > > > on a freshly build 5.0-CURRENT I hereby have an empty /etc/pam.d. > > > > Every attempt to use su(1) results in: > > > > [...] > > > Already fixed. > > Which commit fixed it, specifically? > > Revision 1.4 of pam_handlers.c. > Thanks. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011207163549.E65808>