linux-kernel - Re: [PATCH v2 1/5] fat: allocate persistent inode numbers

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]

Date:	Sun, 09 Sep 2012 18:32:08 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	"Steven J. Magnani" <steve@...idescorp.com>
Cc:	Namjae Jeon <linkinjeon@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>, akpm@...ux-foundation.org,
	bfields@...ldses.org, linux-kernel@...r.kernel.org,
	Namjae Jeon <namjae.jeon@...sung.com>,
	Ravishankar N <ravi.n1@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>
Subject: Re: [PATCH v2 1/5] fat: allocate persistent inode numbers

"Steven J. Magnani" <steve@...idescorp.com> writes:

> On Fri, 2012-09-07 at 16:01 +0900, Namjae Jeon wrote: 
>> Hi. OGAWA.
>> 
>> I checked read-only option for export on FAT.
>> I think that there are 3 approaches as mentioned below.
>> 
>> 1. As per the current scenario – user already has the option of
>> setting ‘ro’ in /etc/exports – so that can also be used to make it
>> read-only.
>> 	
>> 2. Forcefully set to “read-only” while executing FAT export operation.
>> -> As you know, we can set read-only(ro) export in /etc/exports.
>> If we set read-only export regardless of /etc/exports, This is "HACK"
>> and it will work regardless of user setting.
>> 
>> 3. When FAT is mounted with -onfs option,-> Make it ‘ro’ at the mount
>> time itself.
>> -> It is simple to implement, but VFAT of NFS Server will be set to
>> read-only as well as NFS client.
>
> I argue against (2) and (3). A change that drops any possibility of
> NFS-mounting VFAT filesystems read-write will break my use case. Where
> ESTALE is an issue, there are client-side solutions, either mounting
> with lookupcache=none (which admittedly has a severe performance impact)
> or the VFS patches to handle ESTALE that are working their way towards
> mainline. I recognize that not everyone can take advantage of
> client-side features, but options (2) and (3) make life worse for those
> who can.

What is your use case?  I'm assuming current NFS support of FAT is not
unstable behavior even with your patches. Is this true?

Well, this plan is to provide the stable/clean read-only behavior at
first.  After that, make it writable with some limitations (e.g. rename
may be unsupported).

If your patches in -mm is enough for now, we will not need to do those.
Namjae, were you tested it? or what are you thinking?
-- 
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/