linux-kernel - Re: [PATCH v2] NFSv4: Save the owner/group name string when doing open

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-next>] [day] [month] [year] [list]

Message-ID: <20120302050813.GA32761@burratino>
Date:	Thu, 1 Mar 2012 23:08:13 -0600
From:	Jonathan Nieder <jrnieder@...il.com>
To:	Trond Myklebust <Trond.Myklebust@...app.com>
Cc:	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	Chuck Lever <chuck.lever@...cle.com>,
	Rik Theys <Rik.Theys@...t.kuleuven.be>,
	David Flyn <davidf@...bbc.co.uk>
Subject: Re: [PATCH v2] NFSv4: Save the owner/group name string when doing
 open

Hi,

Trond Myklebust wrote:

> [Subject: NFSv4: Save the owner/group name string when doing open]
>
> ...so that we can do the uid/gid mapping outside the asynchronous RPC
> context.
> This fixes a bug in the current NFSv4 atomic open code where the client
> isn't able to determine what the true uid/gid fields of the file are,
> (because the asynchronous nature of the OPEN call denies it the ability
> to do an upcall) and so fills them with default values, marking the
> inode as needing revalidation.
> Unfortunately, in some cases, the VFS will do some additional sanity
> checks on the file, and may override the server's decision to allow
> the open because it sees the wrong owner/group fields.

Thanks!  This patch (commit 6926afd1925a, 2012-01-07) fixes the
following client-side bug[1]:

| Our home directories here are mounted over NFS4. When I log in to machine A
| and run
|
| vim
| :q
|
| and then log into machine B and do:
|
| vim
| :q
|
| I get E137: Viminfo file is not writable: /users/system/rtheys/.viminfo
|
| Every invocation of 'vim and :q' will trigger this.
|
| Explicitely doing a stat of the file fixes this.

Rik Theys bisected and found the bug reproducible after and not before
v2.6.32-rc1~412^2~48^2~15 (NFSv4: Don't do idmapper upcalls for
asynchronous RPC calls, 2009-08-09).

[...]
>  6 files changed, 162 insertions(+), 64 deletions(-)

Now I am wondering what, if anything, can be done to fix this in the
2.6.32.y, 3.0.y, and 3.2.y stable kernels.  The patch looks too big
for inclusion under the usual stable_kernel_rules:

 - It cannot be bigger than 100 lines, with context.

Ideas?
Jonathan

[1] http://bugs.debian.org/659111
    http://thread.gmane.org/gmane.linux.nfs/37230
--
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/