[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

On 12/14/2011 04:43 PM, J.A. Bezemer wrote:

On Wed, 14 Dec 2011, Roger Leigh wrote:

The same argument applies to encryption.  / and /usr both contain a
selection of programs, libraries etc.  If you're encrypting one, why
would you not encrypt all of it?


On one of my relatively low-power portable systems, I have everything encrypted except /boot and /usr. /boot for obvious reasons; /usr because decryption is heavily CPU-bound, making encrypted /usr unworkably slow. Since encryption is for privacy reasons, I need encrypted / because of /etc. (And encrypted /home and /var of course.)

Indeed, this means that programs in /bin and libs in /lib are also encrypted. But this actually does _not_ slow things down: the Linux disk cache is sensibly caching the decrypted data, so often-used stuff from /bin and /lib happily remains in already-decrypted cache. The interesting stuff from /usr is generally too large and too seldomly used to remain cached.

  Yep, that's actually the case for how I got pulled into the fray here. I recently did a squeeze install on the new laptop. I take the laptop out on the world a lot in a powered off state, and thought it would be nice to try Luks encryption for an extra layer of security, mostly for the sake of /home, /var /etc and swap. So I chose the automated partitioning scheme for encrypted LVM on the install disc. I really just wanted the encryption, and at first thought the extra LVM layer was an annoyance. Later, I found the LVM layer was cool to have because / needed much more space than d-i gave it, for backports kernels and headers (for modules for wireless card, etc.), and encrypted /usr (especially without AES acceleration on my processor) was a noticeable performance loss. So I was able to move /usr to the unencrypted partition I made after resizing LVM, expanded /, got backports kernels going (to the joy of the now working sound-card on the new machine), and now everything is working great. ...
  ... With the one caveat which brings us to today, that now I get complaints in the boot log when certain /bin functions are called with dependencies in /usr/lib that haven't been mounted yet. OK, so I admit it, don't shoot me, but the truth of the matter is that these boot log errors haven't yet practically caused me harm in any way (other than the time spent trying to be a responsible admin for my system and track down the reason I'm seeing log errors before they DO jump out and bite me right at the time of a crucial work deadline or whatever).

On 12/14/2011 06:08 PM, Michael Biebl wrote:
I acknowledge that such installations are around (especially
since d-i presents this partitioning scheme in such a prominent way)

   Yep! In fact, one irony in this discussion is that on my own I wouldn't have dreamed of going to the effort to take the initiative to understand working with a separate /usr partition, if not for the fact that d-i had put it out in front of me! But actually, at the end of the day, it worked out well because I (and apparently others) have found that having a generally encrypted system with an unencrypted /usr is actually advantageous. And if someone does snag my laptop and want to yank out the hard drive, I'm really not concerned about them being able to find out what applications I have in my /usr.

On 12/14/2011 03:43 PM, Roger Leigh wrote:

 But the distro itself should take
responsibility for being CONSISTENT, and thus should not say, "Here's
something available to you in /sbin---oh, but you can't actually use it
from there (so to speak).")
The problem here is, can we /be/ consistent?  What is one system's
essential package required for bringing up a working system is
someone else's occasionally-used tool that's not important at all.
Yet both might be required to be on the rootfs.  We can't be all
things to all people in the current state.

  I think we're not fully understanding each other here. You are talking about "one system's essential package" vs. another system's "non-important tool". We can agree that the package priority level (important vs. standard vs. optional) is subjective, and we can agree that in many ways, in many cases, it may be a subjective call as to whether an executable belongs in /sbin vs. /usr/sbin, for example. But what I'm calling "consistency" is as follows: once you have determined the location of all the binary executables across a given repository, you then have a fixed, objective, algorithmic rule for determining the placement of all the libraries in that repository. Here is the explicit algorithm (I don't necessarily expect anyone to actually do it this way, but I'm a mathematician and we mathematicians like to write stuff like this out to either prove the existence of well-defined algorithms, or conversely to expose underlying false assumptions, so let's give it a try):

Library Placement Algorithm (LPA):
1) Consider the set of all possible binary executables that any package in the given repo has chosen to put in /sbin or /bin, and put all such binaries there. (I realize this may not(?) be possible to do with a package manager, namely dpkg/apt, because of the existence of conflicting packages, but rememeber I'm making a point here with an abstract algorithmic presentation. Let's say you manually unpack all packages and put the binary executables there in /(s)bin.)
2) Likewise, consider the set of all libs from all packages in the given repo and place them all in /usr/lib.
3) Run
> ldd /{s,}bin/* | unique
4) Put all the libraries that appear in the output of step 3 in /lib. All other libs can stay behind in /usr/lib (it must be that they are only ever used by something in /usr).
Definition: We say a system satisfies the "FHS-LDD property" if the command
ldd /{s,}bin | grep "=> /usr"
returns nothing.

Definition: We say a repo (or distro?) satisfies the "FHS-LDD property" if any system that installs a subset of the packages from that repo/distro satisfies the FHS-LDD on that system.

My claim: A distro that uses the LPA satisfies the FHS-LDD property in the most efficient manner possible. That is to say, it satisfies the FHS-LDD property for that distro, and any other partitioning of libraries between /usr/lib and /lib which would satisfy the FHS-LDD property for this system would necessary place a set of libraries in /lib which was a superset of that produced by LPA.

  If my claim is valid, then I will have shown that there is in fact a unique, objectively "best" way for libraries to be partitioned between /usr/lib and /lib. Now, I know from professional work experience that this is the point where the more practically grounded folks jump in and kick my abstract mathematician legs out from underneath me and say, "Nice theorem buddy, but in the real world...." OK. So now to the wise folks who said, "We all have better things to be doing than this," good on you! Kudos to anyone who ignores my bug report in favor of doing something with their life that actually matters!


Reply to: