Bug 501484 - Move mount.ecryptfs from /sbin to /usr/sbin
Move mount.ecryptfs from /sbin to /usr/sbin
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: ecryptfs-utils (Show other bugs)
5.4
All Linux
low Severity low
: rc
: ---
Assigned To: Michal Hlavinka
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-19 08:48 EDT by Michal Nowak
Modified: 2013-03-07 21:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-19 09:30:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Nowak 2009-05-19 08:48:17 EDT
Description of problem:

Since mount.ecryptfs is not expected to be usable without mounted /usr (due to dependency on $(ldd /sbin/mount.ecryptfs | grep usr) [1], it makes some sence to move mount.ecryptfs from /sbin to /usr/sbin.

Usually mount.* binaries are in /sbin but they usually don't depend on stuff from /usr.

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

ecryptfs-utils-75-2.el5

How reproducible:

always

Additional info:

[1]

[root@hp-ml370g4-01 trueopenssl-keyfile]# ldd /sbin/mount.ecryptfs | grep usr
	libecryptfs.so.0 => /usr/lib64/libecryptfs.so.0 (0x00002b4be25d7000)
	libssl3.so => /usr/lib64/libssl3.so (0x0000003dde400000)
	libsmime3.so => /usr/lib64/libsmime3.so (0x0000003de1400000)
	libnss3.so => /usr/lib64/libnss3.so (0x0000003de0400000)
	libnssutil3.so => /usr/lib64/libnssutil3.so (0x0000003ddf400000)
	libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x0000003de1c00000)
	libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x0000003de1800000)
	libplc4.so => /usr/lib64/libplc4.so (0x0000003de0c00000)
	libplds4.so => /usr/lib64/libplds4.so (0x0000003ddfc00000)
	libnspr4.so => /usr/lib64/libnspr4.so (0x0000003de0800000)
Comment 1 Michal Hlavinka 2009-05-19 09:00:08 EDT
can you point me to any standard/specification where it's required? I don't see any reason why bother with something like this. And as you've already written, mount helpers are expected in /sbin

I think I can't convince upstream for this change, also I don't see any (big enough) benefit of this for diverging from upstream here.
Comment 2 Michal Hlavinka 2009-05-19 09:30:51 EDT
btw, mount.ecryptfs is not the only binary in /sbin requiring something from /usr

you can check it using:
for f in /sbin/* ; do ldd $f | grep -q '/usr/' && echo $f; done

So I don't think this has enough rationale for changing something and diverging from upstream and all others.

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