linux-kernel - Re: CONFIG_VFAT_FS

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]

Message-Id: <200907092147.26875.Martin@lichtvoll.de>
Date:	Thu, 9 Jul 2009 21:47:18 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	tridge@...ba.org
Cc:	Jan Engelhardt <jengelh@...ozas.de>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Theodore Tso <tytso@....edu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pavel Machek <pavel@....cz>, john.lanza@...ux.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>, corbet@....net,
	jcm@...masters.org, James.Bottomley@...senpartnership.com
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

Am Donnerstag 09 Juli 2009 schrieb tridge@...ba.org:
> Hi Martin,

Hi Tridge,

>  > The question before that would be whether anyone has a comprehensive
>  > list of those tools, cause I think there are quite many. Well at
>  > least those from bigger vendors should be tested I think. Paragon,
>  > Symantec, ...
>
> Do you happen to have any of those handy to test with?

There might be some stuff laying around on some magazine CD/DVDs, but 
honestly I lack the motivation to do any testing. I am still not a fan of 
your patch. And I think the people that are interested in getting the 
patch in should do the testing - not me. Why should I do the work that 
TomTom and other companies not willing or able to fight patents legally 
might be interested in getting done? A motivation would be to think that 
it actually helps towards a software patent free world, but I am not 
convinced that it does.

>  > And has it been tested with Linux tools such as fsck.msdos,
>  > fsck.vfat, parted and partimage? I think it probably has not much
>  > effect on parted and partimage, but what about the fscks?
>
> I tested it with dosfstools (which provides the fsck.vfat on Linux
> distros) and with mtools. Both required patches to work correctly. I
> have submitted both patches to the maintainers of those packages.
>
> The patch to dosfstools makes it skip the invalid 8.3 entries, just as
> windows chkdsk does. The patch is here:
>
>   http://samba.org/tridge/dosfstools.patch1
>
> The patch to mtools is partly cosmetic, and partly to fix a bug in the
> VFAT checksum routine. The code in mtools incorrectly treated a nul
> byte as special in 8.3 directory entries. The patch is here:
>
>   http://samba.org/tridge/mtools.patch1

Okay. But then before activating the your Linux kernel patch as default 
there should a transition time to let distro pick up the newest stuff and 
a safety margin for users to upgrade to them. If it should be activated as 
default at all.

>  > Thus even when the patch only changes the values stored for new - or
>  > rewritten? - files it actively corrupts the meta consistency of the
>  > whole filesystem. To me it is like inserting a defective inode into
>  > a consistent Linux filesystem.

> If the windows implementation is taken as the reference implementation
> then the files are not considered defective. The windows chkdsk will
> (with a small probability) complain of duplicates, but it doesn't
> complain about the entries being defective in any other way.

But you and others consider the characters / bytes your patch put into the 
short names as invalid. How did you come to that conclusion? Either these 
characters are invalid or they are not. An indication would be on what DOS 
would allow me to create. Does it allow me to create files with those 
characters such as blanks or null bytes with simple DOS commands. If not, 
then not checking filenames in short name FAT for invalid names seems to 
be an omission in CHKDSK for me.

Even when fsck.{ext3,whatever}/xfs_check/xfs_repair doesn't moan about "/" 
in filenames I would still consider them invalid and think any software 
which creates those actively corrupts an Ext3, XFS, whatever unix 
filesystem.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)