Bug 1755233

Summary:	Protect services from 'rogue' libraries
Product:	Red Hat Enterprise Linux 8	Reporter:	Renaud Métrich <rmetrich>
Component:	systemd	Assignee:	systemd maint <systemd-maint>
Status:	NEW ---	QA Contact:	Frantisek Sumsal <fsumsal>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.1	CC:	bwelterl, casantos, dtardon, fkrska, msekleta, systemd-maint-list, systemd-maint
Target Milestone:	rc	Keywords:	Reopened
Target Release:	8.0
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-12-02 15:18:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 ...)