Bug 327221

Summary: cryptsetup non-functional since last upgrade via yum
Product: [Fedora] Fedora Reporter: Andrew Pineda <apineda16>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 6CC: agk, dwalsh, dwysocha, mbroz, opensource, prockai, rbiba
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 2.4.6-107.fc6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-05 18:25:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrew Pineda 2007-10-11 04:38:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20070718 Fedora/1.5.0.12-4.fc6 Firefox/1.5.0.12

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 2.6.22.9-61.fc6
Oct 08 23:06:09 Updated: kernel-headers.x86_64 2.6.22.9-61.fc6
Oct 08 23:06:28 Installed: kernel.x86_64 2.6.22.9-61.fc6
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-2.6.22.9-61.fc6

How reproducible:
Always


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
Password:
/dev/mapper/encryptedfs does not exist removing loopback.


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


Additional info:
#!/bin/sh
pathto=$1
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
else
  echo /dev/mapper/$base does not exist removing loopback.
  /sbin/losetup -d $loop
fi

Comment 1 Radek Bíba 2007-10-15 10:48:24 UTC
Looks like a problem with the updated SELinux packages, although I don't see
any problems in logs. See:

# getenforce
Enforcing
# 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
Enforcing
# which cryptsetup
/sbin/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 18:00:43 UTC
2.4.6-107.fc6

Should fix this.

Comment 3 Till Maas 2007-10-15 18:19:49 UTC
I hope this is the correct component now.

Comment 4 Radek Bíba 2007-10-16 07:02:35 UTC
Great! I'm not seeing this issue with 2.4.6-107.fc6 from updates-testing anymore.