On Tue, Nov 23, 2010 at 01:10:24PM -0500, Wietse Venema wrote:
> Thus, the location of Postfix libraries needs to be frozen in at
> build time, or else it needs to be patched into the executable at
> installation time. Some programs require setgid privileges so we
> can't rely in production usage on LD_LIBRARY_PATH which is disgusting
> anyway.
A test build can compile-in a non-default run-path. The final build
will then use the intended production directory. The libraries will have
"SONAME" variants, so this can help too, if the test build is a different
version of Postfix than is currently installed.
> I doubt that providing our own configurable run-time linker is an
> option (i.e. symlink all commands to a stand-alone executable that
> sets up an environment before running the real Postfix command, it
> would not work with setgid programs anyway).
No, we have to freeze the run-path, it can default to /usr/lib on
most platforms, since the library names I have in mind are something
like:
libpostfix-util.so.2.8
so collisions with other software are not a likely issue.
> If the Postfix libraries are to be managed with the system-dependent
> equivalent of ldconfig (instead of hard-wiring the path into the
> executables), then we intrude on the system name space, and we must
> use a globally-unique name like libpostfix instead of libutil,
> libtls, libmaster, etc.
That's what the demo patch does, the SONAME of the library is
libpostfix-util.so.2.8. During the build it also has a libutil.so
symlink, but at run-time only the former is used.
> BTW I saw relative pathnames in your patches. We must avoid relative
> library pathnames, otherwise our setgid commands could be exploited
> with a hard-link trick.
No relative run-paths, -L is not the same as -R.
> > How aggressively do you want to pursue this?
>
> I will consider this for 2.9. It's definitely not a good idea to
> rip apart the build and install tools at the end of the 2.8 release
> cycle.
>
> It is going to be very a time-consuming process to overhaul the
> build and install/update tools, and to get all the system-dependent
> equivalents of SONAME, ldconfig and so on right. I don't think
> that its safe to assume that all systems use the same model as
> Linux.
They don't all use the same model, but most ELF-based systems have
SONAME support in shared libraries, and we can find reasonable
equivalents on many systems. I know that with the primitive demo
model, we can do:
- Linux
- SunOS
- NetBSD
- FreeBSD
- OpenBSD
I am less familiar with HP-UX and AIX, but I expect they won't be
too painful.
> Dynamic linking will save some disk space, but it will hardly save
> memory. The processes that run in multiple instances are smtpd(8),
> cleanup(8) and smtp(8). Once you have a few of those running, the
> savings from dynamic linking become negligible.
If all we got was dynamic linking, it is not compelling, the ultimate
benefit is that we can then support dynamic loading of (say) table
drivers which are linked against the requisite shared libraries.
Table drivers may depend on internal library interfaces that a particular
application does not directly depend on, and so a statically linked
executable may not contain all the pre-requisite entry-points.
--
Viktor.
