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).

(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.

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.

(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.

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)...

(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.

Created attachment 405397 [details]
Patch splitting umount.crypt from the crypto stuff

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.

(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

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.

(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...)

(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.

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.

(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.

(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.

I'll move the libcrypto back to /lib in F14. I will not do it for older Fedora releases though.

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.

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

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

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.