linux-kernel - Re: [pnfs] [GIT BISECT] first bad commit: 1f36f774 Switch !O_CREAT case to use of do

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: <4BAB72C1.6090002@panasas.com>
Date:	Thu, 25 Mar 2010 16:27:13 +0200
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	Benny Halevy <bhalevy@...asas.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	"J. Bruce Fields" <bfields@...i.umich.edu>,
	pNFS Mailing List <pnfs@...ux-nfs.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Doug Nazar <nazard.lkml@...il.com>
Subject: Re: [pnfs] [GIT BISECT] first bad commit: 1f36f774 Switch !O_CREAT
 case to use of do_last()

On 03/25/2010 04:04 PM, Al Viro wrote:
> On Thu, Mar 25, 2010 at 03:45:53PM +0200, Boaz Harrosh wrote:
>>> Does open() of directory _without_ O_DIRECTORY work in e.g. vanilla 2.6.33?
>>> It certainly does for local filesystems and it does for NFSv3; does it work
>>> for NFSv4?
>>
>> In my tests. Every thing is the same safe the client with the above change.
>>
>> So I guess NFSv4 does something different when asked for directory lookup
>> as opposed to files lookup. I guess there is something added/removed to
>> the compound depending on that flag. But I wouldn't know, I am not familiar 
>> with this code. NFSv4 someone?
> 
> OK, what happens if you do the following:
> 
> mount the same fs from two clients
> on one client:
> mkdir /mnt/weird_name_69
> on another:
> echo 'main() {open("/mnt/weird_name_69", 0);}' >/tmp/a.c
> gcc /tmp/a.c
> strace ./a.out
> ls -l /mnt/weird_name_69
> strace ./a.out
> 
> Will the first strace show EISDIR and the second succeed?
> 
> From my reading of that code (2.6.33, before all that stuff got merged),
> we have different behaviour depending on which codepath do we hit.
> If we go through ->d_revalidate(), it sees that it's not S_ISREG() and
> doesn't try to play with atomic open.  If we go through ->lookup(), we
> tell the server to open it, and when it tells us to bugger off (it's a
> directory, NFSv4 doesn't support atomic open for those), -EISDIR is
> passed to caller.  Which leads to open() failing.
> 
> It definitely looks like a bug.  Masked by O_DIRECTORY in 2.6.33.  Bug
> in fs/namei.c patch has exposed that crap both for O_DIRECTORY and !O_DIRECTORY
> cases.
> 
> So immediate fix will need to be along the lines of "add LOOKUP_DIRECTORY
> even on the last step if we have *want_dir" (and I'd probably get rid of
> want_dir then and just abuse nd->flags), but there's a real NFS bug as
> well.

NFS bug, you mean by not being consistent when opening a directory from
cache or when having to fetch it for the first time? I guess...

But I still think it is a problem that the application, git in this case,
did an open(,O_DIRECTORY...) and because of code reuse some low-level did
not see that flag, relaying on the fact that in most systems they don't care.

The nd->flags things looks like the right thing to me. 

And about the NFS thing, let misbehaving applications byte there own bullets.
But a good app like git, does put an O_DIRECTORY on the directory open, and
therefore will receive consistent results, right?

Please push a fix, meanwhile I'm running with this one, but I will need it
in linux-next later.

Thanks for everything
Boaz

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