Bug 559953 - libcrypto.so move from /lib to /usr/lib breaks mount.crypt from pam_mount
libcrypto.so move from /lib to /usr/lib breaks mount.crypt from pam_mount
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openssl (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-29 08:16 EST by Till Maas
Modified: 2010-05-25 14:35 EDT (History)
7 users (show)

See Also:
Fixed In Version: openssl-1.0.0-4.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-25 14:35:38 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)
Patch splitting umount.crypt from the crypto stuff (3.52 KB, patch)
2010-04-08 16:11 EDT, Tomáš Trnka
tomastrnka: review?
Details | Diff

  None (edit)
Description Till Maas 2010-01-29 08:16:22 EST
Description of problem:
/sbin/mount.crypt depends on libcrypto.so, which was moved from /lib to /usr/lib. Some discussion about this can be found in bug #239375, but somehow it was missed that mount.crypt still depends on it.

Version-Release number of selected component (if applicable):
openssl-1.0.0-0.13.beta4.fc12

How reproducible:
always

Steps to Reproduce:
1. $ ldd /sbin/mount.crypt | grep usr


  
Actual results:
	libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x000000328a000000)

Expected results:
no output
Comment 1 Tomáš Trnka 2010-04-08 10:28:47 EDT
Confirming this on current F12 (in fact the problem was here much earlier). It totally breaks auto-unmount of encrypted volumes on system shutdown, since /usr gets unmounted earlier and the umount.crypt helper then fails with missing libcrypto.so.10. I have a very ugly workaround in place (manually copied libcrypto.so.10 to /lib64).

The best way to fix this probably is making umount.crypt a separate binary not requiring libcrypto.so. Or perhaps just move libcrypto.so to /lib{,64} since it doesn't depend on anything in /usr (yes, I know, this is a HUGE change).
Comment 2 Till Maas 2010-04-08 10:49:18 EDT
(In reply to comment #1)
> Or perhaps just move libcrypto.so to /lib{,64} since it
> doesn't depend on anything in /usr (yes, I know, this is a HUGE change).    

This is not a huge change and can be easily done.
Comment 3 Tomas Mraz 2010-04-08 11:26:42 EDT
The only problem is I am not too fond of having one library (libssl) of the openssl package in /usr/lib and second library (libcrypto) in /lib. I am afraid that this would confuse things.
Comment 4 Till Maas 2010-04-08 13:58:08 EDT
(In reply to comment #3)
> The only problem is I am not too fond of having one library (libssl) of the
> openssl package in /usr/lib and second library (libcrypto) in /lib. I am afraid
> that this would confuse things.    

What should be confused by this? ld.so and rpm both support the these directories by default. You could even move both libraries in separate packages and not cause breakage.
Comment 5 Tomáš Trnka 2010-04-08 14:01:15 EDT
Oh, it seems the situation is not so simple...I've split umount.crypt into a separate binary not requiring libcrypto.so, but it didn't help anything. The problem is that umount.crypt also requires /usr/bin/readlink (coreutils)...
Comment 6 Till Maas 2010-04-08 15:01:15 EDT
(In reply to comment #5)
> Oh, it seems the situation is not so simple...I've split umount.crypt into a
> separate binary not requiring libcrypto.so, but it didn't help anything. The
> problem is that umount.crypt also requires /usr/bin/readlink (coreutils)...    

I have reported the readlink problem as bug 580682. Please discuss the split-up also with upstream. I am not sure, whether it is really a good idea, because it will still leave mount.crypt broken so it cannot be used to mount /usr.
Comment 7 Tomáš Trnka 2010-04-08 16:11:06 EDT
Created attachment 405397 [details]
Patch splitting umount.crypt from the crypto stuff
Comment 8 Tomáš Trnka 2010-04-08 16:17:07 EDT
I'm also not completely sure the split-up is the right way to solve this, but it's definitely an alternative if moving libcrypto.so to /lib won't be possible...

I've checked some other distros and it looks like it's common practice to put libcrypto.so to /usr/lib (Mandriva, ALT Linux and OpenSUSE all provide only /usr/lib/libcrypto.so; Ubuntu provides both /lib and /usr/lib).

I've mailed the maintainer requesting his comments on this issue.
Comment 9 Till Maas 2010-04-08 16:30:09 EDT
(In reply to comment #8)

> I've mailed the maintainer requesting his comments on this issue.    

Uh, which maintainer do you mean? I opened a ticket in the pam_mount upstream ticket system:
https://sourceforge.net/tracker/?func=detail&aid=2984122&group_id=41452&atid=430594
Comment 10 Tomas Mraz 2010-04-08 16:37:13 EDT
The patch is not correct - it will most probably not build on new linker in Fedora 13 and 14. You would have to ifdef out all the calls to openssl functions - the best would be to split them into separate object files and link only the necessary object files into the umount.
Comment 11 Tomáš Trnka 2010-04-08 16:43:56 EDT
(In reply to comment #9)
> Uh, which maintainer do you mean? I opened a ticket in the pam_mount upstream
> ticket system:
> https://sourceforge.net/tracker/?func=detail&aid=2984122&group_id=41452&atid=430594    

Well, looking at the upstream git log I deduced that the project is maintained
by Jan Engelhardt, so I mailed him directly...

(In reply to comment #10)
> The patch is not correct - it will most probably not build on new linker in
> Fedora 13 and 14. You would have to ifdef out all the calls to openssl
> functions - the best would be to split them into separate object files and link
> only the necessary object files into the umount.    

That's exactly what I've been trying to avoid...In that case probably moving the libcrypto.so will be both easier and cleaner...
(Can you please provide some pointer to why this won't build? It really surprised me...)
Comment 12 Jan Engelhardt 2010-04-08 16:56:54 EDT
(via mail)
>umount.crypt unnecessarily requires libcrypto.so

umount.crypt is a symlink to mount.crypt, which requires openssl for decrypting keys. Would not call it unnecessary.

mount.crypt is only in /sbin, because mount(8) only searches there IIRC when invoking `mount -t crypt`.

(this report)
>umount.crypt also requires /usr/bin/readlink

I'd love to rip out any extra forking pam_mount has to do. I just need to come up with a readlink implementation for libHX that supports -e and -f-style resolution.


>since /usr gets unmounted earlier and the umount.crypt helper then fails with missing libcrypto.so.10.

umount /usr last ;-)


>it looks like it's common practice to put libcrypto.so to /usr/lib (OpenSUSE)

Well looks like people finally got the gist that putting /usr on a separate filesystem is getting out of fashion. Really, nobody shares /usr over network anymore (if they do, they share the entire root and slap some unionfs around somehow), and it's not a separate fs either because it does not grow uncontrolledly, let alone that if it grows too much, you're in partitioning hell again, and people like to avoid that.
Comment 13 Jan Engelhardt 2010-04-08 17:05:57 EDT
IMHO, this is Fedora-specific, and Fedora has to come up with a solution. I think I remember about openSUSE... it was that the build scripts moaned about /lib/security/pam_mount.so linking to a file in /usr, /usr/lib/libHX.so, but the same script did not analyze main executables like mount.crypt, thus openssl stayed in /usr/lib.

https://bugzilla.novell.com/show_bug.cgi?id=438321


NB tmaas: I did not notice the SF bug report as it was not assigned to me, so I got no mail.
Comment 14 Till Maas 2010-04-08 17:23:16 EDT
(In reply to comment #12)

> Well looks like people finally got the gist that putting /usr on a separate
> filesystem is getting out of fashion. Really, nobody shares /usr over network
> anymore (if they do, they share the entire root and slap some unionfs around
> somehow), and it's not a separate fs either because it does not grow
> uncontrolledly, let alone that if it grows too much, you're in partitioning
> hell again, and people like to avoid that.    

Since Fedora supports an encrypted root partition, splitting off /usr becomes interesting again to reduce the encryption/decryption performance loss by not encrypting it, since it normally only contains public data.
Comment 15 Till Maas 2010-04-08 17:35:03 EDT
(In reply to comment #13)
> IMHO, this is Fedora-specific, and Fedora has to come up with a solution. I
> think I remember about openSUSE... it was that the build scripts moaned about
> /lib/security/pam_mount.so linking to a file in /usr, /usr/lib/libHX.so, but
> the same script did not analyze main executables like mount.crypt, thus openssl
> stayed in /usr/lib.
> 
> https://bugzilla.novell.com/show_bug.cgi?id=438321

The last comment there imho indicates, that taking care of it has just been forgotten:
https://bugzilla.novell.com/show_bug.cgi?id=438321#c7
| I saw in the git repo, that now mount.crypt is also a binary which links
| against openssl. So we need to move openssl also to /lib or find another
| solution. As soon as I build a new package for 11.2 I will look into this
| again. For 11.1 this is still a wontfix, because it works and it is far to late
| now to to change anything here.
Comment 16 Tomas Mraz 2010-04-09 02:36:06 EDT
I'll move the libcrypto back to /lib in F14. I will not do it for older Fedora releases though.
Comment 17 Till Maas 2010-04-09 04:05:55 EDT
Can you please also fix it at least also in F13? If you adjust the SPEC for F14, I will rebuild it for F13 locally and test it, before you make the change for F13 if you want. But we can also ask on devel@fpo if anyone would expect any breakage with this change if you want to have more opinions. Imho only the other way round could cause breakage, like it did.
Comment 18 Fedora Update System 2010-05-18 12:21:39 EDT
openssl-1.0.0-4.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/openssl-1.0.0-4.fc13
Comment 19 Fedora Update System 2010-05-19 15:12:31 EDT
openssl-1.0.0-4.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update openssl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/openssl-1.0.0-4.fc13
Comment 20 Fedora Update System 2010-05-25 14:35:31 EDT
openssl-1.0.0-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

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