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. 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 (/)
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? 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/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 / /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!
, 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
PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76
jeUDB7zXgVWM3pkJGUo2UQ=
=ZKI4
PGP SIGNATURE
To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

The Sunday 2007-02-11 at 02:06 +0100, I wrote:

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.

Let me explain in another way:

Encrypted filesystems using 'twofish256', created after mounting another
filesystem that uses 'twofishSL92', are in fact created using
'twofishSL92' as well, silently.

Thus, the keyword 'twofish256' refers in fact to two different and
incompatible encryptions: to the real or new 'twofish256' (reported by
losetup as 'CryptoAPI/twofish-cbc'), and to the old 'twofishSL92'
(reported by losetup as 'twofish256').

The proof of this is that I can happily mount my 'twofish256' filesystems
as 'twofishSL92' instead.

Now, the first question is: is there another token I can use instead of
'twofish256' that is unique and refers to the real 'twofish256', that is,
to 'CryptoAPI/twofish-cbc'?

And the other question (to SuSE developers) is, how long will the
'twofishSL92' be maintained?

(I have dozens of dvd backups made using 'twofish256' that are in fact
'twofishSL92')
- --
Cheers,
Carlos E. R.
PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

Sa/wUgWJAsAsyakkbm3a74E=
=aBQP
PGP SIGNATURE

To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

The Sunday 2007-02-11 at 12:51 +0100, Ludwig Nussel wrote:

Let me explain in another way:

Encrypted filesystems using 'twofish256', created after mounting another
filesystem that uses 'twofishSL92', are in fact created using
'twofishSL92' as well, silently.

Thus, the keyword 'twofish256' refers in fact to two different and
incompatible encryptions: to the real or new 'twofish256' (reported by
losetup as 'CryptoAPI/twofish-cbc'), and to the old 'twofishSL92'
(reported by losetup as 'twofish256').

Yes, unfortunately there are two incompatible on-disk formats for a
twofish256 encrytion:

Yes, I remember reading that back in 9.3 time.

The proof of this is that I can happily mount my 'twofish256' filesystems
as 'twofishSL92' instead.

Be careful. Writing to a partition that got mounted with the wrong
encryption type may result in irreparable file system corruption.

If I try to mount with twofish256 right after booting, they don't mount,
they fail. It is only after I mount the only explicit twofishSL92
filesystem that the rest can be mounted.

Now, the first question is: is there another token I can use instead of
'twofish256' that is unique and refers to the real 'twofish256', that is,
to 'CryptoAPI/twofish-cbc'?

No. As soon as you load loop_fish2 the twofishSL92 format gets used.

Very unfortunate.

The thing is that I have a three encrypted filesystems, plus dozens of
dvds, some of them created using yast, and which I thought all of them
were using the new system. But, as the old partition (twofishSL92) was
mounted at creation time, all of them are in fact using twofishSL92
although I specified twofish256.

I can't posibly read and reburn all those dvds!

The problem is that Yast, or the kernel, or whatever, has created those
filesystems using loop_fish2 without warning that it was using the old
method.

nimrodel:~ # losetup -a
/dev/loop0: [000d]:2484 (/)
/dev/loop1: [0314]:177 (/Grande/oldcriptadevicefile) encryption=twofish256
/dev/loop2: [1650]:135 (/biggy/crypta.bck_f.x0) encryption=twofish256
/dev/loop3: [0346]:11 (/Disco40/crypta.xfs.f) encryption=twofish256
/dev/loop4: [0703]:131 (/)
/dev/loop5: [034c]:215 (/test_b/crypta.bck_f.x) encryption=twofish256

nimrodel:~ # lsmod | grep "fish\|crypt\|loop"
loop_fish2 12928 4
twofish 43008 1
cryptoloop 3328 1
loop 15112 14 loop_fish2,cryptoloop

Above, loop0 is using twofish and cryptoloop. loop1 is a dd backup of the
old filesystem, predating suse 9.3, using loop_fish2 (both 1 and 0 contain
the same data yet). The rest were created later, suposedly using the new
twofish256, but they are using loop_fish2 instead.

I can, I suposse, recreate the filesystems on disk to the new format. But
the dvd backups are a different history!
- --
Cheers,
Carlos E. R.

PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

Xl2uK2BtJGRjxi7GtB+LNbc=
=YgNb
PGP SIGNATURE

To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

The Wednesday 2007-02-14 at 11:40 +0100, Ludwig Nussel wrote:

Carlos E. R. wrote:
The Sunday 2007-02-11 at 12:51 +0100, Ludwig Nussel wrote:
No. As soon as you load loop_fish2 the twofishSL92 format gets used.

Very unfortunate.

The thing is that I have a three encrypted filesystems, plus dozens of
dvds, some of them created using yast, and which I thought all of them
were using the new system. But, as the old partition (twofishSL92) was
mounted at creation time, all of them are in fact using twofishSL92
although I specified twofish256.

I can't posibly read and reburn all those dvds!

The problem is that Yast, or the kernel, or whatever, has created those
filesystems using loop_fish2 without warning that it was using the old
method.

Yeah, that's an unfortunate situation indeed.

I have been very busy because I had a bad system crash; I blame the IDE
cable (that flat ribbon one with 80 wires) that became faulty with so
many unplugging and replugging while I was trying to install a new disk
and solve the crypto problem and others first my whole home
partition (xfs) in one disk became wholly trashed (even the "label"
disappeared). I even provoked a bug in xfs_repair that I should report
- if I can recover the bug data!

When I had that partition almost recovered, then down went the whole
same disk! This time "/" (ext3) was almost unrecoverable (certainly
unbootable after recovery) and the rest needed extensive fsck. And all
this because I wanted to install a new disk to do a backup

I'm now using 10.2, upgraded from my 9.3 previous full backup. Easier
for me than a fresh install, or because I just wanted to keep the chain
of upgrades since 8.1 :-)

So I didn't see your message.

I had a look at dm-crypt yesterday. Looks like a trivial patch is
sufficient for it to be able to to access legacy images without the
nasty side effects of loop_fish2.

In case you don't mind breaking your whole system with barely tested
software ;-) I've put the patch for dm-crypt.c and shell scripts
that pass the correct parameters to cryptsetup here:
http://www.suse.de/~

I'm certainly interested, but as you know I hosed my system last week,
I am somewhat reluctant to expose it - so, how bad is that "breaking
danger" you mention? :-?

You need to install util-linux-crypto and if you want to recompile
the kernel module also kernel-source.

For example to mount a dvd:
cryptsetup-twofishSL92 foo /dev/hdc
mount /dev/mapper/foo /a

an image:
losetup /dev/loop0 img
cryptsetup-twofish256 bar /dev/loop0
mount /dev/mapper/bar /b

Note that this is experimental. I'd try it with read only dvd images
first. No warranty that it works without breaking stuff. I'd be glad
if someone could confirm that the method works without corrupting
filesystems indeed though (also for pre-9.2 images). Hopefully we
can get rid of loop_fish2 then.

, but I suppose you mean read only for the crypto filesystem, not the
system itself? My system is not encrypted, would that be endangered if I
was testing to read encrypted dvds?

You understand I'm "touchy" right now about such "dangers", don't you? ;-)

At the moment, I have changed my crypto filesystems on the hard disk to the
new system. It is only the DVDs that remain using the old loop_fish2, of
course. If you think my normal filesystem would be safe (it is not
encrypted), then I'm game. I could use another 10.2 system in the same
computer, on a different partition: it wouldn't matter much it that one got
corrupted, as long as there is no danger of propagating the damage to the
rest of unmounted partitions.

Am I too paranoic? ;-)
- --
Cheers,
Carlos E. R.
PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

fvy3Z+XHzNe7ApD/JFXwkb8=
=2TY7
PGP SIGNATURE

To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

The Wednesday 2007-02-14 at 11:40 +0100, Ludwig Nussel wrote:

Yeah, that's an unfortunate situation indeed.

I had a look at dm-crypt yesterday. Looks like a trivial patch is
sufficient for it to be able to to access legacy images without the
nasty side effects of loop_fish2.

In case you don't mind breaking your whole system with barely tested
software ;-) I've put the patch for dm-crypt.c and shell scripts
that pass the correct parameters to cryptsetup here:
http://www.suse.de/~

You need to install util-linux-crypto and if you want to recompile
the kernel module also kernel-source.

For example to mount a dvd:
cryptsetup-twofishSL92 foo /dev/hdc
mount /dev/mapper/foo /a

an image:
losetup /dev/loop0 img
cryptsetup-twofish256 bar /dev/loop0
mount /dev/mapper/bar /b

I'm finally trying this up, but I can't make it go. I compiled
cryptsetup-legacy.tar.gz using the script "compile.sh". I have
kernel-source installed (I'm running my own compiled kernel).

nimrodel:~/bin/cryptsetup-legacy # ./compile.sh
patching file dm-crypt.c
make: Entering directory `/'
make -C ///linux-2.6.18.8-0.1 modules
CC [M] /
Building modules, stage 2.
MDPST
CC /
LD [M] /
make: Leaving directory `/'
ok, now run insmod ./dm-crypt.ko

But:

nimrodel:~/bin/cryptsetup-legacy # insmod ./dm-crypt.ko
insmod: error inserting './dm-crypt.ko': -1 Invalid module format

The kernel log shows:

Apr 16 00:19:05 nimrodel kernel: dm_crypt: disagrees about version of symbol struct_module

My guess is that it doesn't work because I'm not using kernel-default, but
my compiled version. How should I modify the compile script?

Perhaps I should add my own directory to "/usr/src/linux-obj/i386/" (I
don't know how), or copy the modified dm-crypt.c to
/usr/src/linux/drivers/md/ and recompile the whole module tree? The last
one probably needs rebooting.
- --
Cheers,
Carlos E. R.
PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

5any9kGbc0CXE1bERmUtrDo=
=FoSC
PGP SIGNATURE

To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

The Monday 2007-04-16 at 09:27 +0200, Ludwig Nussel wrote:

In this case modify the script to use the directoy where your kernel
sources are. Alternatively patch your kernel sources directly.
just try a 10.3 Alpha version, the dm-crypt patch is included there
already.

10.3 I can't even try because I have 20 partitions in hda, and 16 in hdd:
I understand that the maximum is 15 for the moment.

I have modified 'compile.sh' as follows:

#!/bin/sh
set -e
cp /usr/src/linux/drivers/md/dm{.h,-crypt.c} .
patch -p3 < dm-crypt-nulliv.diff
#make -C /usr/src/linux-obj/i386/default M=$(pwd) modules
make -C /usr/src/linux M=$(pwd) modules
rm -rf .tmp_versions Module.symvers cmd *.o *.mod.*
echo "ok, now run insmod ./dm-crypt.ko"

but insmod fails:

nimrodel:~/bin/cryptsetup-legacy # insmod ./dm-crypt.ko
insmod: error inserting './dm-crypt.ko': -1 File exists

I guess that is because the normal crypto partition is active, but I don't
know; 'lsmod' says:

Module Size Used by

dm_crypt 12552 0
dm_mod 62264 1 dm_crypt
cryptoloop 3968 2
loop 18184 5 cryptoloop

So the alternative is to compile all modules and reboot.

[]

Done that, but now it fails somewhere else:

nimrodel:~/bin/cryptsetup-legacy # ./cryptsetup-twofishSL92 foo /dev/hdc
Enter passphrase:
nimrodel:~/bin/cryptsetup-legacy # l /dev/mapper/
total 0
drwxr-xr-x 2 root root 80 Apr 16 23:41 ./
drwxr-xr-x 11 root root 8200 Apr 16 23:41 /
lrwxrwxrwx 1 root root 16 Apr 16 23:32 control -/device-mapper
brw 1 root root 253, 0 Apr 16 23:41 foo
nimrodel:~/bin/cryptsetup-legacy # mount /dev/mapper/foo a/
mount: Function not implemented

I have no idea what function it is talking about but as far as I know,,
I'm following your instructions.

I forgot to 'insmod dm-crypt', but it is there already:

nimrodel:~/bin/cryptsetup-legacy # lsmod | grep dm_crypt
dm_crypt 12808 1
dm_mod 62264 2 dm_crypt

I noticed that the compile.sh aplies dm-crypt-nulliv.diff, but there is
another file, '' that is not
applied anywhere. Should I? If so, what to and how?

Also, I have that 'foo' mapped, but I don't know how to unmap it. Can I
simply eject the dvd in /dev/hdc? This is new to me.

- --
Cheers,
Carlos E. R.

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

7kr2VgYjJQu4dp+xelomXLw=
=D0iw
PGP SIGNATURE

To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

The Tuesday 2007-04-17 at 09:47 +0200, Ludwig Nussel wrote:

Looks good

nimrodel:~/bin/cryptsetup-legacy # mount /dev/mapper/foo a/
mount: Function not implemented

I have no idea what function it is talking about but as far as I know,,
I'm following your instructions.

Hmm, no idea. Are you sure a/ is a directory? Any suspicious entry in
/var/log/messages? Are you sure the device is not used by cryptoloop
already?

Yes, a/ is a directory I made for the purpose as a second try. hdc can't
be in use, as it is encrypted via the old method that doesn't work once
there is another crypto partition/file active with the new method. Entries
in log not a single message in the kernel log, that one I looked. In
messages I don't remember I have to try again, I don't remember the
exact time I tried, to look it up in the logs.

nimrodel:~ # lsmod | grep dm_crypt
nimrodel:~ # modprobe dm_crypt
nimrodel:~ # lsmod | grep dm_crypt
dm_crypt 12808 0
dm_mod 62264 1 dm_crypt

nimrodel:~ # mkdir foodir

I put the dvd in the drive at this moment, and gnome tries to automount,
failing, of course:

Apr 17 12:36:38 nimrodel kernel: FAT: invalid media value (0xde)
Apr 17 12:36:38 nimrodel kernel: VFS: Can't find a valid FAT filesystem on dev hdc.
Apr 17 12:36:38 nimrodel kernel: hfs: can't find a HFS filesystem on dev hdc.
Apr 17 12:36:38 nimrodel kernel: MINIX-fs: blocksize too small for device
Apr 17 12:36:38 nimrodel kernel: ReiserFS: hdc: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on hdc
Apr 17 12:36:39 nimrodel kernel: Unable to identify CD-RM format.
Apr 17 12:36:39 nimrodel kernel: VFS: Can't find ext3 filesystem on dev hdc.
Apr 17 12:36:39 nimrodel kernel: VFS: Can't find an ext2 filesystem on dev hdc.

So:

nimrodel:~ # cryptsetup-twofishSL92 foo /dev/hdc
Enter passphrase:
nimrodel:~ #

The passphrase is accepted, and the dvd spins up. Nothing in kernel log,
nothing in messages.

nimrodel:~ # l /dev/mapper/
total 0
drwxr-xr-x 2 root root 80 Apr 17 12:38 ./
drwxr-xr-x 11 root root 8220 Apr 17 12:38 /
lrwxrwxrwx 1 root root 16 Apr 17 02:07 control -/device-mapper
brw 1 root root 253, 0 Apr 17 12:38 foo

nimrodel:~ # mount /dev/mapper/foo foodir/
mount: Function not implemented <== takes some five seconds)
nimrodel:~ #

nimrodel:~ # dmsetup info foo
Name: foo
State: ACTIVE
Tables present: LIVE
count: 0
Event number: 0
Major, minor: 253, 0
Number of targets: 1

nimrodel:~ # dmsetup status foo
0 9179136 crypt

Nothing at all in the logs (and I have "KERNEL_LGLEVEL=1" in
/etc/sysconfig/syslog).

Is there something I can do to expand info? How to know what that
"Function not implemented" is refering to? Could it be that the mount
program in 10.2 can not mount device-mapper things? Perhaps I could try
with a plain dvd, if you tell me a procedure.

(I tried again with a intentionally wrong passphrase, and there is no
complain; I don't like that).

The corresponding line in fstab for that dvd is:

/dev/dvd /mnt/dvd.crypta.x9 auto ro,noauto,user,loop,encryption=twofishSL92

The filesystem is XFS. I can mount it once I umount the new style crypt
partitions, or freshly after reboot. After copying over my files, I
disable the sl92 mode by doing:

rmmod loop_fish2 cryptoloop twofish

and then mount my new style partitions again. I did this yesterday, as I
needed those files, and so I tested that the DVD was still ok.

Today I tried with a different dvd.

I noticed that the compile.sh aplies dm-crypt-nulliv.diff, but there is
another file, '' that is not
applied anywhere. Should I? If so, what to and how?

That's a patch for cryptsetup. You only need it if you use the even
older 160bit twofish encryption.

Ah, ok.
- --
Cheers,
Carlos E. R.

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

Yzt84z8Hn3oFuG3IgdKXqrE=
=2JHp
PGP SIGNATURE

To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

The Tuesday 2007-04-17 at 13:56 +0200, Ludwig Nussel wrote:

Is there something I can do to expand info? How to know what that
"Function not implemented" is refering to?

Maybe an strace of mount gives some insight.

I'll try that later.

Could it be that the mount program in 10.2 can not mount device-mapper
things?

No, mount doesn't care where the device comes from.

Perhaps I could try with a plain dvd, if you tell me a procedure.

plain dvd? You mean using an unencrypted dvd via device mapper?

Right, to see if mount can mount such a device.

(I tried again with a intentionally wrong passphrase, and there is no
complain; I don't like that).

There is no complaint at this point with the old method either. It's
up to you/a script/mount to determine whether the decrypted data
makes sense.

let me verify that no, not so:

nimrodel:/etc/postfix # umount /mnt/crypta.mm.x/
nimrodel:/etc/postfix # mount /mnt/crypta.mm.x/
Password:
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

If I type the passphrase (actually, the same one that the dvd uses) with
one letter missing, I get that error above. This one mounts with this line
in fstab:

/biggy/crypta_f.mm.x /mnt/crypta.mm.x xfs noauto,loop,encryption=twofish256 1 2

I think that if I mount manually, using losetup, the error message is a
bit clearer.

The corresponding line in fstab for that dvd is:

/dev/dvd /mnt/dvd.crypta.x9 auto ro,noauto,user,loop,encryption=twofishSL92

The filesystem is XFS.

Is the filesystem properly identified as xfs after you've set up the
dm target? Ie does /lib/udev/vol_id /dev/mapper/foo tell you that
it's xfs?

Let me see:

nimrodel:/etc/postfix # /lib/udev/vol_id /dev/mapper/foo
ID_FS_USAGE=filesystem
ID_FS_TYPE=xfs
ID_FS_VERSIN=

ID_FS_LABEL=crpt_dvd_xfs
ID_FS_LABEL_SAFE=crpt_dvd_xfs
nimrodel:/etc/postfix #

Seems it is.

- --
Cheers,
Carlos E. R.

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

9H9gihxrB4Qk7IJKKzrNbw0=
=VcF+
PGP SIGNATURE

To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

The Tuesday 2007-04-17 at 13:56 +0200, Ludwig Nussel wrote:

Is there something I can do to expand info? How to know what that
"Function not implemented" is refering to?

Maybe an strace of mount gives some insight.

It does indeed. I did:

# strace -ff -o mountrace mount /dev/mapper/foo foodir/

and the 'mountrace' file contains:

brk(0x8088000) = 0x8088000
close(3) = 0
stat64("/sbin/mount.xfs", 0xbf9ec6f0) = -1 ENENT (No such file or directory)
mount("/dev/mapper/foo", "foodir/", "xfs", MS_MGC_VAL, NULL) = -1 ENSYS (Function not implemented)
rt_sigprocmask(SIG_UNBLCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
write(2, "mount: Function not implemented\n", 32) = 32
exit_group(32) = ?

Truly, '/sbin/mount.xfs' does not exist in my system. Either that, or the
non existing function is 'mount()'.

I case I'm jumping to conclussions too fast, I'll try to attach the file
to this email, it's under 6KiB.
- --
Cheers,
Carlos E. R.
PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

Qzq/J1z3MbsgSjEJuab9BCM=
=kVrC
PGP SIGNATURE

PGP SIGNED MESSAGE
Hash: SHA1

The Tuesday 2007-04-17 at 17:24 +0200, Ludwig Nussel wrote:

close(3) = 0
stat64("/sbin/mount.xfs", 0xbf9ec6f0) = -1 ENENT (No such file or directory)
mount("/dev/mapper/foo", "foodir/", "xfs", MS_MGC_VAL, NULL) = -1 ENSYS (Function not implemented)
rt_sigprocmask(SIG_UNBLCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
write(2, "mount: Function not implemented\n", 32) = 32
exit_group(32) = ?

Truly, '/sbin/mount.xfs' does not exist in my system. Either that, or the
non existing function is 'mount()'.

The function does exist, it just throws an ENSYS error :-)

Ah :-(

Is that a bug I should report in bugzilla?

And the missing "/sbin/mount.xfs"? What is that?

Do you
have DVDs with file systems other than xfs? Do they work?

I have plain non encripted dvds, isosomething. They certainly work via
normal plain mount. And the encripted ones work well via the crypto
compatibility thing, which you know means that I can't use newly created
crypto filesystems that use a diferent module (twofish256 vs
CryptoAPI/twofish-cbc), using plain mount.

I also have a concoction of zisofs compressed and xfs encripted
filesystems, but that one is complex to test (it worked last time I tried
some months back).

I have no idea how to mount plain dvds using the device map thing, which
is totally new stuff to me. Do you know a howto somewhere? Man pages
assume you already know what you are looking for, too terse and useless in
this case.
- --
Cheers,
Carlos E. R.
PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

tolHnPn7CWkvg5w8g1ebXpg=
=6lKu
PGP SIGNATURE

PGP SIGNED MESSAGE
Hash: SHA1

The Wednesday 2007-04-18 at 11:30 +0200, Ludwig Nussel wrote:

The function does exist, it just throws an ENSYS error :-)

Ah :-(

Is that a bug I should report in bugzilla?

That's what I'm trying to find out.

Ah, ok, then just tell me when you have something else I could test.

And the missing "/sbin/mount.xfs"? What is that?

Normal, mount first checks if there is a special mount program for a
filesystem.

I see.

I also have a concoction of zisofs compressed and xfs encripted
filesystems, but that one is complex to test (it worked last time I tried
some months back).

I don't understand what you mean. xfs is not an encryption algorithm
it's a filesystem just as zisofs is.

I'll explain.

- First I generate a zisofs compressed dvd image, using mkzftree (1) and
"mkisofs -Z", which I name "zisofs.iso".
- Create an xfs image of an encrypted filesystem (losetup, twofish, etc),
in file '/Disco40/crypta.xfs.f'
- I mount the xfs image, and copy on the resulting filesystem the
iso9660/zisofs dvd image created earlier (zisofs.iso).
- I umount the xfs image, and burn it to a dvd.

The resulting dvd is both compressed and encrypted, and I mount it thus;
in /etc/fstab I have:

/Disco40/crypta.xfs.f /mnt/crypta.x9.dvdbck xfs loop,noauto,user,encryption=twofishSL92 0 0
#Encadenado!
/ /mnt/crypta.x9z.dvdbck auto loop,ro,noauto,user,exec 0 0

The above are the lines for the dvd creation step. For reading the dvd
back, I lost the entries, but they should be:

/dev/dvd /mnt/dvd.crypta.x9 auto ro,noauto,user,loop,encryption=twofishSL92 0 0
/mnt/dvd.crypta.x9/zisofs.iso /mnt/dvd.crypta.x9z auto loop,ro,noauto,user,exec 0 0

First, I do "mount /mnt/crypta.x9.dvdbck", the encrypted xfs image. Next, I
loop mount the compressed image on it, using "mount /mnt/crypta.x9z.dvdbck".

Not too weird, I hope ;-)

(I use twofishSL92 inadvertently, as explained at the start of the thread)

I have no idea how to mount plain dvds using the device map thing, which

The device mapper is of no use there. You can just mount the device
directly.

I know. I just mean that perhaps it is possible to test that way if mount
is capable of mounting a plain dvd via this remaper thing, or if it only
fails when it is encrypted. But maybe that's not an issue, I really don't
know. You are the expert, so whatever you say :-)
- --
Cheers,
Carlos E. R.
PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

qoHR4o5LxZNSY0mbGmlLKKA=
=NYod
PGP SIGNATURE

PGP SIGNED MESSAGE
Hash: SHA1

The Friday 2007-04-20 at 15:14 +0200, Ludwig Nussel wrote:
- First I generate a zisofs compressed dvd image, using mkzftree (1) and
"mkisofs -Z", which I name "zisofs.iso".
- Create an xfs image of an encrypted filesystem (losetup, twofish, etc),
in file '/Disco40/crypta.xfs.f'
- I mount the xfs image, and copy on the resulting filesystem the
iso9660/zisofs dvd image created earlier (zisofs.iso).
- I umount the xfs image, and burn it to a dvd.

What do you need the xfs image for? You can just burn the result of
encrypting zisofs.iso.

I don't know how to encrypt an iso image.

The encryption procedure I know is:

dd if=/dev/zero of=crypta.file bs=1M count=4482
losetup -T -e twofish256 /dev/loop1 crypta.file
mkfs -L "EncriptedBackup" -t xfs /dev/loop1
mount -t xfs /dev/loop1 /mnt/tmp

I don't know how i can adapt mkisofs so that it creates an encrypted
image.

You see, there are man pages on the encryption programs, but I haven't
seen a howto on how to combine all of them.

Anyways. Looks like xfs doesn't work with the sector size of a
cdrom. It works if you attach a loop device first and then use the
loop device for cryptsetup-twofishSL92.
e.g.
losetup /dev/loop0 /dev/hdc
cryptsetup-twofishSL92 foo /dev/loop0

You mean that the devmapping thing will not work? Because I can mount them
ok without that (execept the SL92 compatibility problem, that is).

Ah, I see!

nimrodel:~ # losetup /dev/loop2 /dev/hdc
nimrodel:~ # cryptsetup-twofishSL92 foo /dev/loop2
Enter passphrase:
nimrodel:~ # mount /dev/mapper/foo foodir/
nimrodel:~ # l foodir/
total 4305612

It works! Wow, thanks!

- --
Cheers,
Carlos E. R.
PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

1nPzGYQ/vuYy+HI52ShNQuU=
=Y8qF
PGP SIGNATURE

To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

The Tuesday 2007-04-24 at 10:17 +0200, Ludwig Nussel wrote:

I don't know how to encrypt an iso image.

The encryption procedure I know is:

dd if=/dev/zero of=crypta.file bs=1M count=4482
losetup -T -e twofish256 /dev/loop1 crypta.file
mkfs -L "EncriptedBackup" -t xfs /dev/loop1
mount -t xfs /dev/loop1 /mnt/tmp

I don't know how i can adapt mkisofs so that it creates an encrypted
image.

# mkisofs -J -r -o img.iso stuff
# cp img.iso img.iso.crypted
# losetup /dev/loop0 img.iso.crypted
# cryptsetup-twofish256 foo /dev/loop0
# cp img.iso /dev/mapper/foo
# dmsetup remove foo
# losetup -d /dev/loop0

Ahhh ahhh clap! (mouth hanging open and being manually shut).

(didn't notice that part of the answer, Pine shows the lines starting with
"#" in blue the same as those with ">")

I will have to try that procedure one day

But I have to say that my procedure is faster. I have created the
initial XFS image, all I do is:

- mount it on a loop (R/W)
- copy over those files I want
- umount
- burn.

- mount "normally" (modified fstab line)

The image remains there for reuse many times, encrypted. The iso image has
to be created each time taking care of the maximum size, and then needs a
second encrypted image. In disk I have to keep one non encrypted iso image
at least part of the time.

Frankly, I seem to prefer XFS dvds to IS dvds (encrypted or plain). I can
"create" them with normal tools, moving or copying files, as the image is
read/write and isos are not: size has to be calculated.

The obvious snag is that they are not portable, but so what? ;-)

The second non obvious snag is that the XFS image can not be mounted at
the same time as the burned DVD: they have the same UUID.

Unless there is another problem with them I'm unaware of, of course.

It works! Wow, thanks!

Good to hear. Thanks for testing!

Welcome! :-)
- --
Cheers,
Carlos E. R.

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

7g0ab8UVbjbqHTh3/pJGegY=
=SM9m
PGP SIGNATURE

To unsubscribe, e-mail: opensuse-security+unsubscribe (AT) opensuse (DOT) org
For additional commands, e-mail: opensuse-security+help (AT) opensuse (DOT) org