Bug 697569

Summary: files in /sbin depending on /usr
Product: Red Hat Enterprise Linux 6 Reporter: Karel Volný <kvolny>
Component: ecryptfs-utilsAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED DUPLICATE QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.1   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-04 13:51:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Karel Volný 2011-04-18 15:47:34 UTC
Description of problem:
/sbin/mount.ecryptfs, /sbin/mount.ecryptfs_private and /sbin/umount.ecryptfs_private depend on files in /usr but /usr needs not to be available (mounted) when /sbin binaries are used.

From FHS
(http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES)

"/sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin."

There are several options:

1) If these binaries are not essential, they should be moved to /usr/sbin

2) If these binaries have to stay in /sbin, then they must be able to run without /usr mounted, i.e. the dependencies have to be moved from /usr/lib* to /lib*, or linked statically.

3) If neither of the above is possible (desirable), the exception has to be justified and documented fo further reference (so far I haven't found any relevant docs).

Version-Release number of selected component (if applicable):
ecryptfs-utils-82-6.el6

How reproducible:
always

Steps to Reproduce:
1. run the test /CoreOS/libtirpc/Sanity/bz558937-sbin-dependencies-in-usr
  
Actual results:
:: [   FAIL   ] :: File /sbin/mount.ecryptfs (from ecryptfs-utils-82-6.el6.x86_64) depends on /usr 
:: [   INFO   ] :: The affected dependencies:
:: [   INFO   ] :: - /usr/lib64/libssl3.so (from nss-3.12.8-1.el6_0.x86_64)
:: [   INFO   ] :: - /usr/lib64/libsmime3.so (from nss-3.12.8-1.el6_0.x86_64)
:: [   INFO   ] :: - /usr/lib64/libnss3.so (from nss-3.12.8-1.el6_0.x86_64)
:: [   INFO   ] :: - /usr/lib64/libnssutil3.so (from nss-util-3.12.8-1.el6_0.x86_64)
:: [   FAIL   ] :: File /sbin/mount.ecryptfs_private (from ecryptfs-utils-82-6.el6.x86_64) depends on /usr 
:: [   INFO   ] :: The affected dependencies:
:: [   INFO   ] :: - /usr/lib64/libssl3.so (from nss-3.12.8-1.el6_0.x86_64)
:: [   INFO   ] :: - /usr/lib64/libsmime3.so (from nss-3.12.8-1.el6_0.x86_64)
:: [   INFO   ] :: - /usr/lib64/libnss3.so (from nss-3.12.8-1.el6_0.x86_64)
:: [   INFO   ] :: - /usr/lib64/libnssutil3.so (from nss-util-3.12.8-1.el6_0.x86_64)
:: [   FAIL   ] :: File /sbin/umount.ecryptfs_private (from ecryptfs-utils-82-6.el6.x86_64) depends on /usr 
:: [   INFO   ] :: The affected dependencies:
:: [   INFO   ] :: - /usr/lib64/libssl3.so (from nss-3.12.8-1.el6_0.x86_64)
:: [   INFO   ] :: - /usr/lib64/libsmime3.so (from nss-3.12.8-1.el6_0.x86_64)
:: [   INFO   ] :: - /usr/lib64/libnss3.so (from nss-3.12.8-1.el6_0.x86_64)
:: [   INFO   ] :: - /usr/lib64/libnssutil3.so (from nss-util-3.12.8-1.el6_0.x86_64)

Expected results:
(no such failures)

Additional info:

Comment 2 RHEL Program Management 2011-04-18 16:17:53 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 3 Michal Hlavinka 2011-04-19 08:09:25 UTC
There are four ecryptfs-utils bugs in RHEL 6 and one of them (bug #558932) mentions exactly this issue.

For options 1) and 2) see bug #558932 comment #2,

From my POV this bug is duplicate

Comment 4 Michal Hlavinka 2011-05-04 13:51:13 UTC

*** This bug has been marked as a duplicate of bug 558932 ***