linux-kernel - Re: [PATCH] Sanitize filesystem NLS handling

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: <87vegxdc8i.fsf@duaron.myhome.or.jp>
Date:	Mon, 19 Mar 2007 14:38:21 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	"Alexander E. Patrakov" <patrakov@....usu.ru>
Cc:	LKML <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...l.org>,
	agalakhov@...lrs.uran.ru, Kay Sievers <kay.sievers@...y.org>
Subject: Re: [PATCH] Sanitize filesystem NLS handling

"Alexander E. Patrakov" <patrakov@....usu.ru> writes:

> OGAWA Hirofumi wrote:
>> "Alexander E. Patrakov" <patrakov@....usu.ru> writes:
>> 
>>>> You allow to set any nls to codepage? If so, it is not good.
>>> I did this because it involved less changes. Only FAT treats codepage as a 
>>> number. All other filesystems already allow arbitrary NLS as a codepage 
>>> mount parameter.
>> 
>> I'm saying here, it is not good for vfat.
>
> All valid options (i.e. numbers) are still available. Prohibiting 
> non-numbers is a lot of work (changing module_param_string to 
> module_param_call and validating the passed string, and also changing the 
> code for all filesystems so that they also validate manually-passed codepage 
> string).

Ok.

>>>> No, utf-8 makes completely wrong entry. It's more wrong than other nls.
>>> For any non-UTF-8 based locales, the other NLS is correct and utf8 indeed 
>>> would produce completely wrong characters. But for UTF-8 based locales, utf8 
>>> is the only correct iocharset.
>> 
>> No, iocharset=utf8 is wrong always.
>
> Here we just disagree, but I think I can change your opinion by giving you a 
> correctly configured UTF-8 Japanese system in the form of a LiveCD (note: 
> the kernel doesn't have this patch there). If you can afford ~500 MB of 
> downloads, please do this:

I don't care about "read", because it doesn't corrupt filesystem. I care
about only "write", because it can corrupt filesystem.

If it's read-only, I'll not care at all, and will agree.

>> Why I can't use utf8 for jfs or something, and use other nls for vfat?
>
> Because you'll get a mismatch between the userspace locale and the iocharset 
> used by the kernel in at least one of these two cases. The mismatch will 
> result in the following:
>
> 1) Your system (e.g., the "ls" command) will not correctly interpret 
> filenames written by known-good setups.
> 2) Known-good setups will not correctly interpret filenames written by your 
> system.
>
> What probably happened in your case is that you have no known-good jfs-based 
> setup and are the only user of your jfs disk, and thus can't see (2). It 
> looks like you don't use UTF-8 userspace locale. Then, the on-disk filenames 
> on your jfs filesystem are wrong, but your system misinterprets them, and 
> two errors seem to cancel each other (but this still doesn't make it a 
> correct setup).

All are user policy. The users can switch locale and
G_FILENAME_ENCODING and something else, some app can switch it even
runtime, and I think kernel shouldn't have user policy, right?
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
-
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/