linux-kernel - Re: iso9660 vs udf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Sep 2007 21:37:47 +0200
From:	"Andries E. Brouwer" <Andries.Brouwer@....nl>
To:	Karel Zak <kzak@...hat.com>, jack@...e.cz
Cc:	"Andries E. Brouwer" <Andries.Brouwer@....nl>,
	linux-kernel@...r.kernel.org
Subject: Re: iso9660 vs udf

On Wed, Sep 19, 2007 at 03:23:27PM +0200, Karel Zak wrote:
> On Sat, Sep 15, 2007 at 11:49:31PM +0200, Andries E. Brouwer wrote:
> > What goes wrong on the mount side is that when it hesitates between
> > iso9660 and udf it decides for udf when seeing "NSR02".
> > Maybe the heuristics in mount should be tuned.
> 
> Also try:
>      # blkid -c /dev/null /dev/cdrom

# blkid -c /dev/null /dev/hdc
/dev/hdc: TYPE="udf" 

>      # /lib/udev/vol_id  /dev/cdrom

# /sbin/vol_id /dev/hdc
ID_FS_USAGE=filesystem
ID_FS_TYPE=udf
ID_FS_VERSION=
ID_FS_UUID=
ID_FS_LABEL=Wisk1956-82
ID_FS_LABEL_SAFE=Wisk1956-82

>  Maybe vol_id provides better information -- the udf/iso code in
>  libblkid seems poorer that in libvolume_id.

I think the blkid code started out as a copy of the code in mount(8),
but since then they may have developed independently.

Anyway, mount, blkid, vol_id all think that they see udf.
But the kernel cannot handle this type of udf.

>  I'd like to see the CD image (or at least first 2Mb).

Ha, I hoped that someone would say that.
(But do you still want it if I say that it is mostly
a kernel problem?)

By the way, unfortunately a CD image does not work quite the same
as the real thing.

In udf/lowlevel.c you can read

	unsigned int
	udf_get_last_session(struct super_block *sb) {
		...
		i = ioctl_by_bdev(bdev, CDROMMULTISESSION, ...

and this ioctl will succeed on a CDROM, but fail on a loop device. Ach.

Now what goes wrong? In udf/inode.c/udf_current_aext there is support
for allocation types ICBTAG_FLAG_AD_SHORT (0) and ICBTAG_FLAG_AD_LONG (1)
and for no other types. However, ECMA 167 writes (in 14.6.8):

	0-2 Shall be interpreted as a 3-bit unsigned binary number as follows.
	The value 0 shall mean that Short Allocation Descriptors are used.
	The value 1 shall mean that Long Allocation Descriptors are used.
	The value 2 shall mean that Extended Allocation Descriptors are used.
	The value 3 shall mean that the file shall be treated as though
	it had exactly one allocation descriptor describing an extent
	which starts with the first byte of the Allocation Descriptors field
	and has a length, in bytes, recorded in the Length of Allocation
	Descriptors field.
	The values of 4-7 are reserved for future standardisation.

and this particular CD-ROM uses type 3.
So, I guess udf_current_aext() must be updated a bit.

Andries

[will send you a bzip2'd copy of the start of the CD-ROM separately]

>  Karel Zak  <kzak@...hat.com>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/