linux-ext4 - Re: [PATCH RESEND v2 21/25] ext4: Add encoding mount options

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: <878t37masg.fsf@collabora.co.uk>
Date:   Tue, 09 Oct 2018 10:53:19 -0400
From:   Gabriel Krisman Bertazi <krisman@...labora.co.uk>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: [PATCH RESEND v2 21/25] ext4: Add encoding mount options

"Theodore Y. Ts'o" <tytso@....edu> writes:

> On Mon, Sep 24, 2018 at 05:56:51PM -0400, Gabriel Krisman Bertazi wrote:

> It seems to me that adding support for setting the encoding parameters
> via mount options is a bad idea.  The encoding is going to impact
> directory hash; which means if the file system has directories created
> using, say, ASCII as its encoding, and then the encoding changes to
> UTF-8, directory lookups won't work correctly.  So I think this commit
> needs to be dropped, and support for setting the encoding needs to be
> added to e2fsprogs as the primary way encoding settings are made.

The main reason I had this patch is debugging, so I am ok with dropping
it.

> We need e2fsprogs support before this feature is ready for production
> use, since e2fsck needs to be able to properly rebuild directories.
>
> Do you agree?

I have support for e2fsprogs in the branch I mentioned in the cover
letter, I will rebase and start submitting it in the next iteration.

I am only supporting encoding selection at mkfs time, so I don't need to
rebuild the hashes, (except for fsck errors).  I'm not sure I care about
changing the encoding after creation time, since this complicates
things, for instance by increasing the risk of file name collisions.
I'm also only allowing case-sensitiveness configuration changes on empty
directories for the same reason.

I will start by submitting kernel/e2fsprogs patches to reserve the
superblock bits.  Do we agree on the current superblock format?

Also, what is the best list to send the NLS patches?  fsdevel?

-- 
Gabriel Krisman Bertazi