linux-kernel - Re: Long file names in VFAT broken with iocharset=utf8

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] [day] [month] [year] [list]

Date:	Wed, 9 May 2007 14:27:04 +0400
From:	Andrey Borzenkov <arvidjaar@...l.ru>
To:	Roland Kuhn <rkuhn@....physik.tu-muenchen.de>
Cc:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: Long file names in VFAT broken with iocharset=utf8

On Monday 07 May 2007, Roland Kuhn wrote:
> Hi!
>
> On 7 May 2007, at 20:27, OGAWA Hirofumi wrote:
> > Roland Kuhn <rkuhn@....physik.tu-muenchen.de> writes:
> >> PATH_MAX specifically counts _bytes_ not characters, so UTF-8 does
> >> not matter. ISTR that PATH_MAX was 256 at some point, but I just
> >> quickly grepped /usr/include and found various mention of 4096, so
> >> where's the central repository for this configuration item? A hard-
> >> coded value of 256 somewhere inside the kernel smells like a bug.
> >
> > There is a nasty issue here. FAT is limited by 255 unicode chars or
> > so.
> > So, we would need to count number of unicode chars of filename.
>
> No, we don't. At least not when looking at the POSIX spec, which
> explicitly mentions _bytes_ and _not_ unicode characters. So, to be
> on the safe side, FAT filesystems would need to support a NAME_MAX of
> roughly 6*255+3=1533 bytes (not to mention the hassles of forbidden
> sequences, etc.; do we need to count zero-width characters?)

How is this issue related to character *width* at all?

> and 
> report it through pathconf() to userspace, then userspace could do
> with that whatever it liked.
>
> What happened to: "file names are just sequences of octets, excluding
> '/' and NUL"? Adding unicode parsing to the kernel is completely
> useless _and_ a big trouble maker.
>

Who speaks about unicode parsing? UCS2 - UTF-8 transformation does and 
requires no parsing; this is simply conversion between on-disk and in-kernel 
representation (like endian conversion). Anyway we are doing it now already; 
how support for larger name length limit changes it?

-andrey

Content of type "application/pgp-signature" skipped