Bug 327221 - cryptsetup non-functional since last upgrade via yum
cryptsetup non-functional since last upgrade via yum
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
6
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2008-01-05 13:25:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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: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 06:48:24 EDT
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 14:00:43 EDT
2.4.6-107.fc6

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.