linux-ext4 - utf8only option

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

Message-ID: <4F42C2E8.6000303@v.loewis.de>
Date:	Mon, 20 Feb 2012 23:02:16 +0100
From:	"Martin v. Löwis" <martin@...oewis.de>
To:	linux-ext4@...r.kernel.org
Subject: utf8only option

Many systems use UTF-8 locales these days, resulting in file names
encoded in UTF-8. On such systems, file names not encoded in UTF-8
can cause problems, making it desirable to detect these problems when
the file is created, not when someone attempts to open the file or
display the directory contents.

In order to support this better on Linux, I implemented an utf8only
file system option for ext4. It is an RO_COMPAT option: systems not
supporting it will still be able to mount the volume read-only, but
cannot create new files. Systems supporting the option will refuse
creation of new files with names that are invalid UTF-8 with an
EILSEQ errno code.

This feature was inspired by the ZFS utf8only property.

Unlike the ZFS feature, I propose that the option cannot just
be specified when the file system is created, but also later on
using tune2fs. The kernel will reject creation of new non-UTF-8
names; existing non-UTF-8 names can still be accessed. This will
allow users to run convmv on the volume to convert any remaining
non-UTF-8 names.

I'm uncertain how fsck should deal with non-UTF-8 files when it
sees that the option is turned on. I can imagine these alternatives:
- ignore the issue, letting the user use convmv
- convert the file names to UTF-8, assuming they are currently
  Latin-1. This assumption may be incorrect; it may also create
  conflicts with existing files in the same directory.
- convert the file names to UTF-8, assuming an encoding specified
  on the command line (essentially integrating convmv into fsck).
  This may still cause conflicts with existing files.
- convert non-UTF-8 bytes to private-use characters, encoded
  in UTF-8. This has a very low but non-zero chance of creating
  conflicts, and it is possible to locate the converted files
  afterwards by looking at those PUA characters.
- move the files to lost+found, renaming them uniquely
  (possibly in a way that still allows to recreate the original
   directory and file name, e.g.
  <dir-inum>-<inum>-nameWithPUAchars)

The patch makes no attempt to provide Unicode normalization.

I just noticed that the specific RO feature selected conflicts
with the one that was just reserved; I'll update the patches
shortly.

The patches are in the utf8only branches of

https://github.com/loewis/linux
https://github.com/loewis/e2fsprogs

Please let me know what you think.

Regards.
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html