linux-kernel - Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH

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: <18940.3862.34000.615391@samba.org>
Date:	Sat, 2 May 2009 19:15:02 +1000
From:	tridge@...ba.org
To:	Matthew Wilcox <matthew@....cx>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Christoph Hellwig <hch@...radead.org>,
	Steve French <smfrench@...il.com>,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>,
	Ogawa Hirofumi <hirofumi@...l.parknet.co.jp>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Michael Tokarev <mjt@....msk.ru>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

Hi Matthew,

 > So what's the purely technical argument for including this patch?

There is no purely technical argument for including this patch, as the
patch removes functionality without removing much code.

However, if you are willing to concede that there are good
non-technical arguments for wanting to "get the VFAT out" then
choosing the best way to achieve that is most definately a technical
decision, and that is what we can discuss here. 

Unfortunately I am unable to discuss any of the non-technical reasons
for why "get the VFAT out" might be a good idea in the first
place. That is damn frustrating, but it is just how things are.

So, on the technical front, what we need is a patch that keeps as much
functionality in Linux as possible while also giving us a high degree
of confidence that the patch will make the non-technical issues go
away.

This patch is one way to achieve that. There are certainly other
patches that would be possible, each with a different trade off in
terms of functionality loss. 

So, from a technical point of view the patch is pretty simple. When
the option is enabled you can still read all VFAT filesystems, with
any filenames (long or short). If you try to create a file with a long
filename then you get -1/ENAMETOOLONG. That means that Linux users
running a kernel with this patch enabled can plug in VFAT formatted
USB keys which have been written on windows/macosx etc systems, and
see all the files. When the Linux user wants to give a file to a
person running Windows, and they want to use a FAT based filesystem to
do it, then the Linux user has to choose a 8.3 name for the file. That
is a nuisance, but is a lot better than nothing.

Cheers, Tridge
--
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/