linux-kernel - Re: [PATCH vfat] allow retrieving entries with trailing dots

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: <87y6hzni82.fsf@devron.myhome.or.jp>
Date:	Thu, 11 Mar 2010 21:41:33 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Philippe De Muyter <phdm@...qel.be>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH vfat] allow retrieving entries with trailing dots

Philippe De Muyter <phdm@...qel.be> writes:

>> > This is unavoidable.
>
> We could perhaps reduce the disadvantage by moving the logic (test first
> with the trailing dots, and then without if needed) into fat_search_long
> instead of putting it in vfat_find as my patch proposal does.  This way
> the name to find would only be compared once to unrelated entries,
> instead of possibly twice as my patch does.
>
> But therefore I need your help : fat_search_long isn't easy to read/modify.
>
> The logic could be modified as such :
>     - if the searched name contains trailing dots, first compare
> 	the truncated part to the same length of the directory entry
>     - if they are the same, test the length of the rest of the directory entry
> 	- if length_of_rest is 0, this could be the matching entry,
> 	    but there could be a better one later; keep searching till the end.
> 	- if length_of_rest is not 0, compare the rest with the trailing dots
> 	    - if rests are equal, we have found it; return
> 	    - if rests are unequal, continue searching
>
>> 
>> We would be able to introduce new mount option to do it if needed.
>
> A new mount option should be the last programming option.  It is better to
> automatically do the right thing than to require the user to figure out
> he must add a mount option in /etc/fstab or whatever.  Remember this is
> for hot-plug disks.

Sorry, but I'm not thinking this is primary one. So, requiring option
for it to avoid disadvantage of normal users, it sounds good.

>> This changed vfat_find(), so, this patch will change the behavior of all
>> callers more or less. And the behavior seems to be really strange, you
>> can remove "a.", but you can't create it?
>
> Yes, you can remove any existing file, but if you want to create a file, 
> the name creation rules are kept unchanged. So, creating "a." will
> succeed, it will actually be called "a" on disk, but you can still refer
> to it as "a." : that will succeed.  That's the strange part of the behavior
> but that part is already present for compatibility reasons nor you nor me
> can do anything about :(
>
>> The behavior sounds random, right?
>
> It's a compromise to avoid creating name entries that are not universally
> accepted, but to allow accessing existing files and directories.
>
> The mount option could be useful then to allow the creation of file and
> directory names with trailing dot, but consistency between getdents and
> stat/open must be automatic.

No, this breaks consistency. With this patch, unlink("a."), then
open("a.", O_CREAT) and write(), the result depend on existent
files. This patch is providing two files on one name.

Thanks.
-- 
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/