Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 287068 - sys-fs/cryptsetup[static] depends on libs in /usr
Summary: sys-fs/cryptsetup[static] depends on libs in /usr
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High minor with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 297560 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-09-30 12:32 UTC by Dirk Heinrichs
Modified: 2014-08-21 04:01 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Heinrichs 2009-09-30 12:32:44 UTC
The summary says it all:

% ldd /sbin/cryptsetup|grep usr
        libpopt.so.0 => /usr/lib/libpopt.so.0 (0xb7ec4000)
        libcryptsetup.so.0 => /usr/lib/libcryptsetup.so.0 (0xb7eb6000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7e28000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7e23000)

This should be allowed for a program which could be involved in booting a system. Those libs should be installed int /lib (that's especially true for the one that comes with the package itself).

Building it statically doesn't quite work because it would require libdevmapper.a which would be provided by a statically linked lvm2. However, trying to rebuild lvm2 statically tries to pull in baselayout-1 on a baselayout-2 system.

Reproducible: Always

Steps to Reproduce:
Install dynamically linked cryptsetup (on a system with encrypted LVs).
Reboot :(
Actual Results:  
Fails to find libpopt.so -> no dmcrypt mappings created.
Comment 1 Dirk Heinrichs 2009-09-30 12:35:10 UTC
(In reply to comment #0)

> This should be allowed for a program which could be involved in booting a
> system.

Ooops, there's missing a big fat "not", of course. "This should not be allowed...".
Comment 2 SpanKY gentoo-dev 2009-10-01 21:43:01 UTC
so build it with USE=static
Comment 3 Dirk Heinrichs 2009-10-02 05:28:11 UTC
(In reply to comment #2)
> so build it with USE=static

Please read the above again. I tried.
Comment 4 Dirk Heinrichs 2009-10-02 05:41:15 UTC
Static linking is not the best thing to do. This is especially true in an application that is related to system security. Let's assume there is a security flaw found in libgcrypt and fixed soon after. I install the new version and all dynamically linked apps are secure again. But unfortunately had cryptsetup linked statically :-( Too bad.

It's a simple rule of thumb: Whatever is installed into / should have its deps installed there, too. No need for insecure static linking.
Comment 5 SpanKY gentoo-dev 2009-10-02 06:51:10 UTC
dont waste your breath on static vs security lectures

the libraries cryptsetup uses really have no chance of being moved to /

now that i think about it, the ebuild i was looking at was a local one.  you must have enabled USE=dynamic.  the entire point of this flag was to workaround usage of libs in a separate /usr.

you didnt post `emerge --info` like every bugzilla page tells you to.  cryptsetup is working fine for me on stable x86.
Comment 6 Dirk Heinrichs 2009-10-02 07:03:05 UTC
(In reply to comment #5)
> dont waste your breath on static vs security lectures
> 
> the libraries cryptsetup uses really have no chance of being moved to /

Why not?

> now that i think about it, the ebuild i was looking at was a local one.  you
> must have enabled USE=dynamic.

Of course I do.

>  the entire point of this flag was to workaround
> usage of libs in a separate /usr.

I really would prefer a proper solution over a workaround.

> you didnt post `emerge --info` like every bugzilla page tells you to. 
> cryptsetup is working fine for me on stable x86.

I'm on unstable x86, here's the relevant USE flags for cryptsetup.

# paludis -q cryptsetup
* sys-fs/cryptsetup
    gentoo:                  0.1-r3 1.0.5-r1 1.0.6-r2 {:0}
    installed:               1.0.6-r2* {:0}
    Description:             Tool to setup encrypted devices with dm-crypt
    Homepage:                http://luks.endorphin.org/ http://code.google.com/p/cryptsetup/
    License:                 GPL-2
    Installed time:          Wed Apr 22 06:30:09 2009
    Use flags:               (dynamic) (nls) (-selinux)
    From repositories:       gentoo
    Installed using:         paludis-0.36.0

However, as written above, I tried building it statically, but it fails:

i686-pc-linux-gnu-gcc -O2 -march=native -fomit-frame-pointer -pipe -Wl,-O1 -o cryptsetup -static cryptsetup.o  /usr/lib/libpopt.a ../lib/.libs/libcryptsetup.a -ldevmapper /usr/lib/libgcrypt.a -L/usr/lib /usr/lib/libgpg-error.a -luuid                                                             
make[2]: Leaving directory `/gentoo/build/sys-fs-cryptsetup-1.0.6-r2/work/cryptsetup-1.0.6/src'                                                    
make[1]: Leaving directory `/gentoo/build/sys-fs-cryptsetup-1.0.6-r2/work/cryptsetup-1.0.6'                                                        
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/ld: cannot find -ldevmapper                                                 
collect2: ld returned 1 exit status
make[2]: *** [cryptsetup] Error 1

This is because lvm2 is not built statically either. If I try to do this, it wants to pull in baselayout-1
Comment 7 Dirk Heinrichs 2009-10-02 08:55:52 UTC
(In reply to comment #5)

> cryptsetup is working fine for me on stable x86.

Do you actually use it while booting your system?
Do you have /usr on a separate, encrypted partition/LV?
Comment 8 SpanKY gentoo-dev 2009-10-02 16:48:45 UTC
there's no point in encrypting /usr as it's full of code that is readily available on the internet, so i dont waste time on it.  i encrypt my home partition and it works fine of course on stable systems.

static linking with device-mapper is about the only issue here that needs to be resolved
Comment 9 Carsten Lohrke (RETIRED) gentoo-dev 2009-12-19 22:36:25 UTC
*** Bug 297560 has been marked as a duplicate of this bug. ***
Comment 10 Florian Philipp 2010-06-25 18:33:59 UTC
(In reply to comment #8)
> there's no point in encrypting /usr as it's full of code that is readily
> available on the internet, so i dont waste time on it.  i encrypt my home
> partition and it works fine of course on stable systems.
> 

You don't need to have /usr encrypted in order to make dynamic linking a problem. It is sufficient to have /usr on a separate partition and make use of /etc/conf.d/dmcrypt on baselayout-1.

During boot, it tries to unlock the partitions specified in dmcrypt before mounting anything else, including /usr.
Comment 11 SpanKY gentoo-dev 2010-06-25 19:40:37 UTC
only if you configure your system that way
Comment 12 Florian Philipp 2010-06-30 16:15:34 UTC
(In reply to comment #11)
> only if you configure your system that way
> 

Where and how do I configure this? Is this documented anywhere?
Of course, I could hack the init scripts but I wouldn't call this configuration ;)
Comment 13 SpanKY gentoo-dev 2010-07-06 13:14:37 UTC
dont run the script in the boot runlevel if you dont have weird sep partitions like /usr or /var
Comment 14 Florian Philipp 2010-07-06 16:18:53 UTC
(In reply to comment #13)
> dont run the script in the boot runlevel if you dont have weird sep partitions
> like /usr or /var
> 

Ehm, I don't want to sound impolite, so please accept my apology if the following sounds wrong: You do notice that I'm a user and therefore - unwise stated otherwise - you should expect my system to run with the software versions you devs deem safe and supported, i.e. "stable" without any ACCEPT_KEYWORDS except the default one?

That means I'm running baselayout-1. You don't explicitly activate the dmcrypt init-script in baselayout-1 and therefore there is (AFAIK) no sane way to change the script from boot runlevel to something else.
Comment 15 SpanKY gentoo-dev 2010-07-06 20:10:18 UTC
baselayout-1 is largely EOL.  i could lie and say we're working on a solution if it makes you feel better, but the fact of the matter is that things work as i described in baselayout-2/openrc, so we're not going to do heavy work in baselayout-1.  we'll simply let things stabilize.
Comment 16 Florian Philipp 2010-07-07 20:37:31 UTC
(In reply to comment #15)
> baselayout-1 is largely EOL.  i could lie and say we're working on a solution
> if it makes you feel better, but the fact of the matter is that things work as
> i described in baselayout-2/openrc, so we're not going to do heavy work in
> baselayout-1.  we'll simply let things stabilize.
> 

I'm fine with that. Saying "fixed in next major release" is something different from "problem does not exist". ;)

In the mean time, for me it is an acceptable yet ugly workaround to simply copy the necessary libraries and their respective symlinks from /usr/lib64 to /lib64. For me (and the record, in case another poor soul stumbles upon this), that's libpopt, libgcrypt and libgpg-error.

As I've said, ugly as hell, but it works and is easy enough to revert once the root cause is gone.