Bug 697569 - files in /sbin depending on /usr
Summary: files in /sbin depending on /usr
Keywords:
Status: CLOSED DUPLICATE of bug 558932
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ecryptfs-utils
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Michal Hlavinka
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-18 15:47 UTC by Karel Volný
Modified: 2011-05-04 13:51 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-04 13:51:13 UTC
Target Upstream Version:


Attachments (Terms of Use)

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 ***


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