linux-kernel - Re: [PATCH v3 7/7] NFSD: Pass share reservations flags to VFS

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:	Mon, 11 Mar 2013 15:36:38 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Pavel Shilovsky <piastry@...rsoft.ru>,
	linux-kernel@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	wine-devel@...ehq.org
Subject: Re: [PATCH v3 7/7] NFSD: Pass share reservations flags to VFS

On Mon, Mar 11, 2013 at 03:05:40PM -0400, Jeff Layton wrote:
> knfsd has some code already to handle share reservations internally.
> Nothing outside of knfsd is aware of these reservations, of course so
> moving to a vfs-level object for it would be a marked improvement.
> 
> It doesn't look like this patch removes any of that old code though. I
> think it probably should, or there ought to be some consideration of
> how this new stuff will mesh with it.
> 
> I think you have 2 choices here:
> 
> 1/ rip out the old share reservation code altogether and require that
> filesystems mount with -o sharemand or whatever if they want to allow
> their enforcement
> 
> 2/ make knfsd fall back to using the internal share reservation code
> when the mount option isn't enabled
> 
> Personally, I think #1 would be fine, but Bruce may want to weigh in on
> what he'd prefer.

#1 sounds good.  Clients that use deny bits are few.  My preference
would be to return an error to such clients in the case share locks
aren't available.

(We're a little out of spec there, so I'm not sure which error.  I think
the goal is to notify a human there's a problem with minimal collateral
damange.

NFS4ERR_SERVERFAULT ("I'm a buggy server, sorry about that!") would
probably result in an IO error to the application.

SHARE_DENIED strikes me as unsafe: an application would be in its rights
not to even check for that e.g. in the case of an exclusive create.

Maybe DELAY?  Kind of ridiculous, but blocking the application
indefinitely would probably get someone's attention quickly enough
without doing any damnage.)

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