Bug 327221 - cryptsetup non-functional since last upgrade via yum
cryptsetup non-functional since last upgrade via yum
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-11 00:38 EDT by Andrew Pineda
Modified: 2008-01-05 13:25 EST (History)
7 users (show)

See Also:
Fixed In Version: 2.4.6-107.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-05 13:25:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew Pineda 2007-10-11 00:38:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20070718 Fedora/ Firefox/

Description of problem:
Since my last yum system upgrade, cryptsetup does not work to either open (luksOpen) or format (luksFormat) filesystems (on files via loopback). The command exits with no error messages. The The files themselves are intact as I can open them on an i386 FC6 laptop that I have not patched yet. I can also open them on the affected machine using the pre-compiled AMD64 cryptsetup binary at http://luks.endorphin.org/dm-crypt. The latter is a static binary built for a 2.4 kernel. /sbin/cryptsetup appears to be a statically linked binary, so I don't see how it could be broken. Here are the packages that were changed during the last upgrade:

Oct 08 23:04:47 Updated: kdelibs.i386 3.5.7-1.fc6
Oct 08 23:05:02 Updated: kdelibs.x86_64 3.5.7-1.fc6
Oct 08 23:05:30 Updated: kdebase.x86_64 3.5.7-1.fc6
Oct 08 23:05:43 Updated: kdebase.i386 3.5.7-1.fc6
Oct 08 23:05:44 Updated: perl-Net-DNS.x86_64 0.61-1.fc6
Oct 08 23:05:46 Updated: selinux-policy.noarch 2.4.6-94.fc6
Oct 08 23:05:48 Updated: postgresql-libs.i386 8.1.10-1.fc6
Oct 08 23:05:49 Updated: postgresql-libs.x86_64 8.1.10-1.fc6
Oct 08 23:05:52 Updated: tzdata.noarch 2007h-1.fc6
Oct 08 23:06:06 Installed: kernel-devel.x86_64
Oct 08 23:06:09 Updated: kernel-headers.x86_64
Oct 08 23:06:28 Installed: kernel.x86_64
Oct 08 23:06:30 Updated: elinks.x86_64 0.11.3-1.fc6
Oct 08 23:06:40 Updated: selinux-policy-targeted.noarch 2.4.6-94.fc6

The kernel upgrade also forced me to rebuild my NVidia graphics drivers.

Version-Release number of selected component (if applicable):
cryptsetup-luks-1.0.3-2.3.fc6 kernel-

How reproducible:

Steps to Reproduce:
1. Create a luks encrypted file system on a file (this step fails if bug exists at "cryptsetup luksFormat /dev/loopN name"). If you have a pre-existing file you can try script below to try to open it. 
2. use the script supplied below to mount it. (argument is path to file to be mounted)
3. Script detects that nothing created under /dev/mapper and removes loopback.

Actual Results:
sudo ~/bin/copen2 ./encryptedfs
/dev/mapper/encryptedfs does not exist removing loopback.

Expected Results:
sudo ~/bin/copen ./encryptedfs
Enter LUKS passphrase: 
key slot 0 unlocked.
Command successful.

Additional info:
base=`basename $pathto`
loop=`/sbin/losetup -f`
/sbin/losetup $loop  $pathto
/sbin/cryptsetup -v luksOpen $loop $base
if [ -e /dev/mapper/$base ]; then
  mkdir /mnt/$base
  mount /dev/mapper/$base /mnt/$base
  echo /dev/mapper/$base does not exist removing loopback.
  /sbin/losetup -d $loop
Comment 1 Radek Bíba 2007-10-15 06:48:24 EDT
Looks like a problem with the updated SELinux packages, although I don't see
any problems in logs. See:

# getenforce
# cryptsetup luksOpen /dev/hda3 stuff  <- nothing happens here
# setenforce 0
# cryptsetup luksOpen /dev/hda3 stuff
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful. <- YAY!

Also see another workaround:
# getenforce
# which cryptsetup
# cp /sbin/cryptsetup /tmp
# ls -Z /sbin/cryptsetup /tmp/cryptsetup
-rwxr-xr-x  root root system_u:object_r:lvm_exec_t:s0  /sbin/cryptsetup
-rwxr-xr-x  root root user_u:object_r:tmp_t:s0         /tmp/cryptsetup
# /tmp/cryptsetup luksOpen /dev/hda3 stuff
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful. <- interesting, the same cryptsetup binary, executed from
another directory, with another context, works

What do you think, Daniel? Thanks.
Comment 2 Daniel Walsh 2007-10-15 14:00:43 EDT

Should fix this.
Comment 3 Till Maas 2007-10-15 14:19:49 EDT
I hope this is the correct component now.
Comment 4 Radek Bíba 2007-10-16 03:02:35 EDT
Great! I'm not seeing this issue with 2.4.6-107.fc6 from updates-testing anymore.

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