openSUSE Security
Threads by month
- ----- 2024 -----
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1997 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1996 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
May 2007
- 39 participants
- 21 discussions
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have bumped into a weird problem with encrypted filesystems.
It appears there are two incompatible types that use the same options in
the cryptotab file.
It's difficult to explain.
I have replaced an old disk wit a bigger one. The old one had an encrypted
partition predating SuSE 9.2. Over the time, I have created other
partitions and copied files to encrypted filesystems in DVD, and never had
problems.
However, I discovered, after switching to the new disk, that although I
could load the new encrypted partition, I was unable to load any of the
old ones. In order to mount any of those encrypted filesystems, first I
have to mount the obsolete (pre 9.2) one, then the rest - except that in
that case, I'm unable to mount the new one.
For example. I boot, and the "/etc/init.d/boot.crypto" script mounts the
main encrypted partition fine. I then manually try to mount one of the
auxiliaries:
nimrodel:~/cripta.problem # losetup -a
/dev/loop0: [000d]:2484 (/dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15)
encryption=CryptoAPI/twofish-cbc
nimrodel:~/cripta.problem # mount /mnt/crypta.x/
Password:
mount: /dev/loop1: can't read superblock
However, if edit the /etc/cryptotab to mount the obsolete one (I had to
copy it over from the old disk for this purpose):
/dev/loop1 /Grande/oldcriptadevicefile /A60/cripta xfs twofishSL92 noatime
and now, I mount it:
nimrodel:~/cripta.problem # /etc/init.d/boot.crypto start
Activating crypto devices using /etc/cryptotab ...
Please enter passphrase for /Grande/oldcriptadevicefile: Switching to SuSE 9.2 loop_fish2 compatibility mode.
Please enter passphrase for /Grande/oldcriptadevicefile:
fsck 1.38 (30-Jun-2005)
/sbin/fsck.xfs: XFS file system.
See the notice about 9.2 compatibility mode? Once this mode is activated,
I can mount any of the partitions or backups I created during last year:
(fstab)
/biggy/crypta.bck_f.x0 /mnt/crypta.x xfs noauto,loop,encryption=twofish256 0 0
nimrodel:~/cripta.problem # mount /mnt/crypta.x/
Password:
nimrodel:~/cripta.problem # mount /mnt/dvd.crypta.x/
Password:
nimrodel:~/cripta.problem # mount | grep encryption
/dev/hda15 on /cripta type xfs (rw,noatime,loop=/dev/loop0,encryption=twofish256)
/Grande/oldcriptadevicefile on /A60/cripta type xfs (rw,noatime,loop=/dev/loop1,encryption=twofishSL92)
/biggy/crypta.bck_f.x0 on /mnt/crypta.x type xfs (rw,loop=/dev/loop2,encryption=twofish256)
/dev/hdc on /mnt/dvd.crypta.x type xfs (ro,noexec,nosuid,nodev,loop=/dev/loop3,encryption=twofish256)
nimrodel:~/cripta.problem # losetup -a
/dev/loop0: [000d]:2484 (/dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15) encryption=CryptoAPI/twofish-cbc
/dev/loop1: [0314]:177 (/Grande/oldcriptadevicefile) encryption=twofish256
/dev/loop2: [1650]:135 (/biggy/crypta.bck_f.x0) encryption=twofish256
/dev/loop3: [000d]:5490 (/dev/dvd) encryption=twofish256
See? everything is mounted, old, medium, new (remember that "loop1" is in
9.2 compatibility mode, explicitly).
The thing is, I first have to mount the new partition, using "encryption=twofish256".
Second thing, I have to mount the old one, using "encryption=twofishSL92",
which switches something in the system to "SuSE 9.2 loop_fish2
compatibility mode".
Finally, I can mount the new partitions using "encryption=twofish256" as
well, but which were created while there was already a mounted partition
in 9.2 mode (during last year).
That is, it seems that if twofishSL92 is active, new partitions in
twofish256 need the old mode to be active to be able to mount!
If not, they give errors:
Filesystem "loop1": Disabling barriers, not supported by the underlying device
XFS mounting filesystem loop1
XFS: Log inconsistent (didn't find previous header)
XFS: failed to find log head
XFS: log mount/recovery failed: error 5
XFS: log mount failed
Feb 11 01:04:58 nimrodel kernel: XFS: Log inconsistent (didn't find previous header)
Feb 11 01:04:58 nimrodel kernel: XFS: failed to find log head
Feb 11 01:04:58 nimrodel kernel: XFS: log mount/recovery failed: error 5
Feb 11 01:04:58 nimrodel kernel: XFS: log mount failed
My problem is now that I have to keep using the old compatibility mode! I
have to keep this in the cryptotab file, and in that precise order:
/dev/loop0 /dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15 /cripta xfs twofish256 noatime
/dev/loop1 /Grande/oldcriptadevicefile /A60/cripta xfs twofishSL92 noatime
And I will have to keep for ever that twofishSL92 file I do not want,
simply in order to activate the old compatibility mode so that I can mount
my backup dvds which do not use twofishSL92 but twofish256, but still need
twofishSL92!
Or, can I change some definition in the cryptotab file so that I can mount
"twofish256" filesystems that require "twofishSL92" to be
previously activated?
- --
Cheers,
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFFzmwLtTMYHG2NR9URAk9uAJ0f15fnbFkuPOoUAtUWlhMwiVJrywCfbOId
jeUDB7zXgVOWM3pkJGUo2UQ=
=ZKI4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-security+help(a)opensuse.org
2
22