Date: Thu, 5 Aug 1999 15:43:18 +1000 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: jdp@polstra.com Cc: hackers@freebsd.org Subject: Re: NSS Project Message-ID: <99Aug5.152359est.40396@border.alcanet.com.au> In-Reply-To: <199908050344.UAA02817@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra <jdp@polstra.com> wrote: >Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> wrote: >> Assar Westerlund <assar@sics.se> wrote: >> >Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> writes: >> >> We need to be able to build an application that has no dynamically >> >> loaded code for recovery purposes (/stand and /sbin) as well as for >> >> security. >> > >> >Isn't that the same problem as with PAM? >> >> Quite probably PAM has the same problem. I haven't bumped into it >> with PAM, so I can't be sure. > >When you're not sure, it's really best to find out or keep quiet >on the mailing list. Maybe I should have worded it differently: In order to build statically linked applications, both PAM and NSS have to solve a similar problem. If it can or has been solved for PAM (which I wasn't sure about), the same (or a very similar) solution will work for NSS. > PAM doesn't work in statically-linked >executables" -- which is false. It works fine. I apologize if I gave anyone the impression that you couldn't build statically linked executables with libpam. > It is implemented >using a linker set approach which you are encouraged to investigate in >the sources. A similar approach should work for NSS, though a case could probably be made for having statically linking mean `only rely on local files'. >> the situation where init can fail to load ... because the appropriate >> encryption library is on a partition that isn't mounted yet I should also point out that init doesn't use PAM at present, so this problem can't occur. (The downside if that if the root password doesn't use the default encryption method, init won't be able to validate it). > But nothing would be qualitatively >different if we went to an all-dynamic scheme (which I hope we will do >some day). I recall having a similar static-vs-dynamic discussion with you a couple of years ago. My position was (and still is) that for most purposes dynamic linking is a definite advantage, but we should continue to permit static linking for applications that want it (which Sun doesn't). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Aug5.152359est.40396>