Bug 1755233 - Protect services from 'rogue' libraries
Summary: Protect services from 'rogue' libraries
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemd
Version: 8.1
Hardware: All
OS: All
medium
medium
Target Milestone: rc
: 8.0
Assignee: systemd maint
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-25 06:46 UTC by Renaud Métrich
Modified: 2023-08-14 11:27 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-02 15:18:18 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3468321 0 None None None 2020-02-04 20:52:07 UTC

Description Renaud Métrich 2019-09-25 06:46:36 UTC
Description of problem:

Some products register their libraries in the library search path by
creating an entry in /etc/ld.so.conf.d/ directory.
This is not an issue unless a library conflicts with a system library in
standard path /usr/lib64 (this is distribution dependent, may also be
/usr/lib), which happens quite frequently.

Adding LD_LIBRARY_PATH for system services guarantees that standard
libraries will be used, preventing critical issues such as D-Bus daemon
not starting when 'libexpat' has been overloaded by some non-system
library for example, causing boot issues (nothing works then).

See Upstream PR: https://github.com/systemd/systemd/pull/13640

I doubt Upstream will want this patch, but IMHO RHEL needs this anyway
to protect critical services from failing/hanging at boot
(typically DBus is affected, which then impacts systemd, NetworkManager, ...).

This would solve many boot failure cases we see.


Version-Release number of selected component (if applicable):

All releases of systemd


How reproducible:

Always


Steps to Reproduce:
1. Install an incompatible library (e.g. /broken/libexpat.so*, see private attachment)

  # mkdir /broken && tar xzf libexpat.tar.gz -C /broken
  # echo "/broken" > /etc/ld.so.conf.d/broken.conf
  # ldconfig

2. Reboot

Actual results:

Hang of the boot after starting D-Bus


Expected results:

No issue

Comment 2 Jan Synacek 2019-09-25 08:30:50 UTC
I may be stating the obvious, but LD_LIBRARY_PATH is used exactly for that -- overloading libraries. We shouldn't provide hacky crutches for user errors and misbehaving third-party software. But that's just my opinion, so I'm not going to close this.

Comment 3 Jan Synacek 2019-09-25 08:32:04 UTC
Also note that by providing such "hardening", you may very well restrict other users who need to use LD_LIBRARY_PATH.

Comment 4 Renaud Métrich 2019-09-25 08:47:30 UTC
It won't restrict other users because that LD_LIBRARY_PATH is set for executing Services only and this will just make /usr/lib64 the first search path, the libraries will still be searched in paths set in ld.so.conf.
This just protects system services from failing.
Also, it's not really a user error to set additional paths in ld.so.conf, it's fully supported, the only issue here is when libraries conflict.

I consider not having LD_LIBRARY_PATH set to /usr/lib64 just makes systemd even more fragile (and you know what admins think of systemd ...)


Note You need to log in before you can comment on or make changes to this bug.