Bring back rpaths, it's okay to use them if you're careful.

[o11c]

Let me start off by saying, any time that LD_LIBRARY_PATH must be used is a bug. Not just a user experience bug, but an absolute bug. The sole purpose of LD_LIBRARY_PATH is for local administrators to override the default for debugging or something, it must never be used by upstream or by distro, in any package. Never, ever, ever.

Now, looking at distro policies:

• All setuid/setgid/setcap executables must have no relative rpaths, because the executable may be hard-linked to load arbitrary code.
• There must not be absolute rpaths to the build directory after installation (relative rpaths are okay, subject to the previous rule), because unprivileged users can write to the build directory to load.
• The standard directories, (/lib/, /lib64/, /usr/lib/, and /usr/lib64/), must never be specified in an rpath. (Note, however, that if you install a library to the standard paths, you must run ldconfig afterward)
• It is possible to extend the list of standard directories by adding a file to /etc/ld.so.conf.d/, but this is the job of the distro, not upstream.
• If a library is installed outside the standard directories (either because it is private, or because it is being installed as an unprivileged user), you must emit an rpath.
• Rust can avoid the problem of .so version changes in basic library packages such as libc, simply by including the SONAME of all the system libraries in the hash (this doesn't strictly need to be done now, only if such a change happens, and could be pushed to the distros problem (there probably should be a way to specify that anyway), but it shouldn't be hard so it might as well be done now so that an answer can be given to distros who ask).

Finally, a brief mention of Windows. Prior discussion has claimed that Windows does not support rpaths, but this is missing one criticial thing: Windows binaries have a hard-coded rpath of ., because each binaries bundling its own libraries has been the normal route, not the exception.

The result of misunderstanding the implications of rpath has been much breakage, and telling users to use environment variables that are only intended for debugging.

[emberian]

Pass --enable-rpath to configure, or -C rpath to rustc.

[emberian]

In particular they aren't gone, just not the default. Should they be? (Can reopen if that is the purpose of this issue)

[thestinger]

Let me start off by saying, any time that LD_LIBRARY_PATH must be used is a bug. Not just a user experience bug, but an absolute bug. The sole purpose of LD_LIBRARY_PATH is for local administrators to override the default for debugging or something, it must never be used by upstream or by distro, in any package. Never, ever, ever.

I don't think Rust is using LD_LIBRARY_PATH for anything outside of the build process. It's perfectly sane for a user to make use of it to add libraries in their home directory to the search path and it's also fine to use it as part of a build process.

relative rpaths are okay, subject to the previous rule

Relative paths are occasionally okay, but most binaries shouldn't have them. It's incorrect for the compiler to set these by default because it doesn't know how the binaries / libraries are going to be arranged when they're deployed. I'm not aware of any other language adding these by default. The layout of packages varies per distribution, and you're going to have a lot of issues on an operating system like NixOS if you hardcode assumptions about paths into the binaries.

• It is possible to extend the list of standard directories by adding a file to /etc/ld.so.conf.d/, but this is the job of the distro, not upstream.

The directory in is /etc because it's part of the site configuration. If it was only for the distribution, it would be in /usr/. It's best to install libraries to the standard location, but it's fine to add a directory to the library search path if there's a good reason for it.

The only sane use case for an rpath is to create /usr/lib/package-name/ and hide bundled libraries in there. If the dependencies aren't specific to the package, then it's a misuse of rpaths. It would be best if Rust stopped putting libraries in /usr/lib completely and had the target / compiler use the same libraries from rustlib. The names are never going to collide with system libraries, so it's fine to add the host's rustlib directory to the library search path. The subdirectory structure is just organization to distinguish Rust crates from other libraries.

Finally, a brief mention of Windows. Prior discussion has claimed that Windows does not support rpaths, but this is missing one criticial thing: Windows binaries have a hard-coded rpath of ., because each binaries bundling its own libraries has been the normal route, not the exception.

Windows doesn't permit adding arbitrary relative rpaths, and that's the issue. The experience across platforms shouldn't be radically different because we depend on relative rpaths on some systems but not others. I'm not aware of other languages making implicit usage of rpaths, and I found it very surprising.

The result of misunderstanding the implications of rpath has been much breakage, and telling users to use environment variables that are only intended for debugging.

You're misconstruing a different opinion with lack of understanding. The LD_LIBRARY_PATH variable isn't just for debugging anyway. The security issues it brings are caused by it existing as an option, not by making use of it.

[thestinger]

@cmr: I'm not aware of any other language doing it. Speaking as a distribution packager and someone who pays a lot of attention to security issues, it's not okay to have implicitly added runtime search paths. This will result in vulnerabilities in far more cases than you would expect.

The relative paths added automatically by the Rust compiler are going to be inherently messed up because of the quirks of the staged build process. The current install is essentially messed up because it's putting duplicate versions of the crates for the compiler earlier in the library search path for all binaries. It should just be in rustlib with a single directory added to the host's library search path and all Rust crates located in there. Either that or all of the host's libraries should be in /usr/lib.

[o11c]

Right now it is impossible to run the rust nightly package at all, since it can't find its own libraries; this gives me no opportunity to pass any flags. The documented way to use rustc right now is "put LD_LIBRARY_PATH in the environment".

@cmr The user should never have to specify whether they want rpaths or not, there is a simple rule: if the libraries are in the standard path, never use rpath. If they are not in the standard path, always use an absolute rpath to it. Relative rpaths are useful in other languages during make test, but that is the domain of cargo, which I think has it under control.

@thestinger I might be wrong about /etc/ld.so.conf.d, but that is what I've observed.

[thestinger]

@o11c: In my Arch package, I'm planning on removing all of the duplicate /usr/lib/ crates and adding /usr/lib/rustlib to /etc/ld.so.conf.d. The /usr/lib/rustlib directory would then be the standard place to install Rust crates. At the moment, it just hacks around the build system by adding symlinks from /usr/lib to /usr/lib/rustlib for all of the crates since I wanted to get rid of the duplication. It would be a bug if the ABI varied between the target libraries matching the host and the compiler libraries since there are never any stage1/stage2 differences and it has never been a problem.

[o11c]

Well, in the Ubuntu packages, all the .so files are in /usr/lib/rust/rust-nightly/lib and /usr/lib/rust/rust-nightly/lib/rustlib/x86_64-unknown-linux-gnu/lib, and neither of those can be found at all.