On 2020-08-08 06:58, Greg Troxel wrote:
ld and ld.so have basically the same priorities. However, a little more digging revealed that rpath is dying a slow death in the linux world and at some point in the future LD_LIBRARY_PATH will likely have the highest priority even on RHEL/CentOS.Jason Bacon <outpaddling%yahoo.com@localhost> writes:On 2020-07-29 17:26, Greg Troxel wrote:Jason Bacon <outpaddling%yahoo.com@localhost> writes:The point here is not to add system lib dirs, but to exclude ${PREFIX}/lib. It's my understanding that RPATH overrides all other search paths, so this would ensure that pkg_install binaries don't get fooled into using the wrong libs by LD_LIBRARY_PATH and such.That is not my understanding at all. I expect LD_LIBRARY_PATH, any RPATH values, and system libs, in that order. I would suggest that you experimentally validate this rather than make assumptions.This was not an assumption. From the ld man page: The linker uses the following search paths to locate required shared libraries: 1. Any directories specified by -rpath-link options. 2. Any directories specified by -rpath options. The difference between -rpath and -rpath-link is that directories specified by -rpath options are included in the executable and used at runtime, whereas the -rpath-link option is only effective at link time. Searching -rpath in this way is only supported by native linkers and cross linkers which have been configured with the --with-sysroot option. 3. On an ELF system, for native linkers, if the -rpath and -rpath-link options were not used, search the contents of the environment variable "LD_RUN_PATH". 4. On SunOS, if the -rpath option was not used, search any directories specified using -L options. 5. For a native linker, search the contents of the environment variable "LD_LIBRARY_PATH".Wow, this is really different between BSD and Linux. Is that about the run-time linker from the binary, or about ld(1) and how it finds things at link time? From ld.elf_so on NetBSD 8: The linker will search for libraries in three lists of paths: 1. A user defined list of paths as specified in LD_LIBRARY_PATH and ld.so.conf(5). The use of ld.so.conf should be avoided as the setting of a global search path can present a security risk. 2. A list of paths specified within a shared object using a DT_RPATH entry in the dynamic section. This is defined at shared object link time. 3. The list of default paths which is set to /usr/lib.
So the only option for protecting users form themselves will probably be to scrub the env, which I'm also doing already. auto-pkgsrc-setup generates two variants of env modules and startup scripts:
1. One that scrubs the env of PATH, LD_LIBRARY_PATH, CFLAGS, etc. This is necessary for clean package builds and recommended for most users running them.
2. Another tagged "-non-exclusive" which leaves the users' env intact and simply prepends pkgsrc dirs to PATH.
This is based on 8 years experience using pkgsrc on CentOS and figuring out ways to prevent problems. Except for a few edge-cases like curl requiring mozilla-rootcerts and reasonable arguments against making it a dependency, we've had almost no surprises in the past few years.I don't think any core pkgsrc change is necessary since this is already fairly well-supported by PREFER_PKGSRC/PREFER_NATIVE. I would only aim to educate people about their use.If the consensus is that on Linux, because of old libs (FC derivatives) or unstable libs, people should steer hard to PREFER_PKGSRC, we should set the defaults that way. As pkgsrc maintainers, we curate decisions in the best interests of most users, in addition to providing knobs for others. You have made what feels like a strong argument that using base libs that could have been avoided isn't generally a good idea.
The potential issues with changing shared libs on bleeding-edge distros is more speculative, but I think pretty obvious. On CentOS, S.O. versions almost never change, so we don't worry about ABI changes. But we occasionally had issues early-on with Yum libraries appearing or disappearing, which causes similar results if PREFER_PKGSRC is not used. A Yum autoremove can remove a shared lib that pkgsrc depends on, causing existing pkgsrc binaries to fail. Likewise, installing a Yum package with different build options than the pkgsrc equivalent might cause pkgsrc binaries to fail if they decide to grab the Yum version. The same could happen with Debian's apt, Gentoo Portage, or any other foreign installations. When pkgsrc manages most of its own dependencies, issues like these become almost non-existent. I don't recall encountering one since I started using PREFER_PKGSRC=yes, except a few WIP packages that didn't utilize rpath properly.