linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
To: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
Cc: Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org>,
	Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	wine-devel-5vRYHf7vrtgdnm+yROfE0A@public.gmane.org,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs
Date: Tue, 11 Dec 2012 08:11:35 -0500	[thread overview]
Message-ID: <20121211081135.136ee0d0@tlielax.poochiereds.net> (raw)
In-Reply-To: <20121210164116.GC13327-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>

On Mon, 10 Dec 2012 11:41:16 -0500
"J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> wrote:

> On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
> > The problem is the possibility of denial-of-service attacks here. We
> > can try to prevent them by:
> > 1) specifying an extra security bit on the file that indicates that
> > share flags are accepted (like we have for mandatory locks now) and
> > setting it for neccessary files only, or
> > 2) adding a special mount option (but it it probably makes sense if
> > we decided to add this support for CIFS and NFS only).
> 
> In the case of knfsd and samba exporting a common filesystem, you'd also
> want to be able to enforce it on the exported filesystem.
> 

Sorry for chiming in late on this, but I've been looking at this
problem from the other end as well, from the POV of a fileserver. For
there, you absolutely do want to have some mechanism for enforcing this
on local filesystems. 

Currently, file servers generally enforce share reservations
internally. The upshot is that they're not aware when other tasks
outside the server modify a file. This is also problematic too in many
common fileserving situations -- when exporting files via both NFS and
SMB, for instance.

One thing that's important to note is that there is already some
support for this in the kernel. The LOCK_MAND flag and its associates
are intended for just this purpose. Samba even already calls into the
kernel to set LOCK_MAND locks, but the kernel just passes them through
to the fs. Rumor has it that GPFS does something with these flags, but
I can't confirm that.

Of course, LOCK_MAND is racy since you can't set it on open(), but it
might be nice to use that as a starting point for trying to add this
support.

At the very least, if we're going to do this, we need to consider what
to do with the LOCK_MAND interfaces. As a starting point for
discussion, here's a patch that I was playing with a few months ago. I
haven't had much time to really spend on this project, but it may be
worthwhile to consider. It works, but I'm not sure about the
semantics...

-----------------------------[snip]--------------------------------

locks: add enforcement of LOCK_MAND locks

The LOCK_MAND lock mechanism is currently a no-op for any in-tree
filesystem. The flags are passed to f_ops->flock, but the standard
flock routines basically ignore them.

Change this by adding enforcement against other LOCK_MAND locks. Also,
assume that LOCK_MAND also implies LOCK_NB.

Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 fs/locks.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index 814c51d..736e38b 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -625,6 +625,43 @@ static int posix_locks_conflict(struct file_lock *caller_fl, struct file_lock *s
 	return (locks_conflict(caller_fl, sys_fl));
 }
 
+/*
+ * locks_mand_conflict - Determine if there's a share reservation conflict
+ * @caller_fl: lock we're attempting to acquire
+ * @sys_fl: lock already present on system that we're checking against
+ *
+ * Check to see if there's a share_reservation conflict. LOCK_READ/LOCK_WRITE
+ * tell us whether the reservation allows other readers and writers.
+ *
+ * We only check against other LOCK_MAND locks, so applications that want to
+ * use share mode locking will only conflict against one another. "normal"
+ * applications that open files won't be affected by and won't themselves
+ * affect the share reservations.
+ */
+static int locks_mand_conflict(struct file_lock *caller_fl,
+				struct file_lock *sys_fl)
+{
+	unsigned char caller_type = caller_fl->fl_type;
+	unsigned char sys_type = sys_fl->fl_type;
+	fmode_t	caller_fmode = caller_fl->fl_file->f_mode;
+	fmode_t sys_fmode = sys_fl->fl_file->f_mode;
+
+	/* they can only conflict if they're both LOCK_MAND */
+	if (!(caller_type & LOCK_MAND) || !(sys_type & LOCK_MAND))
+		return 0;
+
+	if (!(caller_type & LOCK_READ) && (sys_fmode & FMODE_READ))
+		return 1;
+	if (!(caller_type & LOCK_WRITE) && (sys_fmode & FMODE_WRITE))
+		return 1;
+	if (!(sys_type & LOCK_READ) && (caller_fmode & FMODE_READ))
+		return 1;
+	if (!(sys_type & LOCK_WRITE) && (caller_fmode & FMODE_WRITE))
+		return 1;
+
+	return 0;
+}
+
 /* Determine if lock sys_fl blocks lock caller_fl. FLOCK specific
  * checking before calling the locks_conflict().
  */
@@ -633,9 +670,11 @@ static int flock_locks_conflict(struct file_lock *caller_fl, struct file_lock *s
 	/* FLOCK locks referring to the same filp do not conflict with
 	 * each other.
 	 */
-	if (!IS_FLOCK(sys_fl) || (caller_fl->fl_file == sys_fl->fl_file))
-		return (0);
+	if (!IS_FLOCK(sys_fl))
+		return 0;
 	if ((caller_fl->fl_type & LOCK_MAND) || (sys_fl->fl_type & LOCK_MAND))
+		return locks_mand_conflict(caller_fl, sys_fl);
+	if (caller_fl->fl_file == sys_fl->fl_file)
 		return 0;
 
 	return (locks_conflict(caller_fl, sys_fl));
@@ -1646,7 +1685,7 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned int, cmd)
 	if (!filp)
 		goto out;
 
-	can_sleep = !(cmd & LOCK_NB);
+	can_sleep = !(cmd & (LOCK_NB|LOCK_MAND));
 	cmd &= ~LOCK_NB;
 	unlock = (cmd == LOCK_UN);
 
-- 
1.7.11.7

  parent reply	other threads:[~2012-12-11 13:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-06 18:26 [PATCH 0/3] Add O_DENY* flags to fcntl and cifs Pavel Shilovsky
2012-12-06 18:26 ` [PATCH 2/3] CIFS: Add O_DENY* open flags support Pavel Shilovsky
2012-12-06 18:26 ` [PATCH 3/3] CIFS: Use NT_CREATE_ANDX command for forcemand mounts Pavel Shilovsky
     [not found] ` <1354818391-7968-1-git-send-email-piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org>
2012-12-06 18:26   ` [PATCH 1/3] fcntl: Introduce new O_DENY* open flags for network filesystems Pavel Shilovsky
2012-12-06 19:49   ` [PATCH 0/3] Add O_DENY* flags to fcntl and cifs Alan Cox
2012-12-06 19:57     ` Jeremy Allison
2012-12-06 20:13       ` Jeremy Allison
2012-12-06 21:31       ` Theodore Ts'o
     [not found]         ` <20121206213133.GB4821-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2012-12-06 21:33           ` Jeremy Allison
2012-12-06 21:37             ` Theodore Ts'o
     [not found]               ` <20121206213727.GC4821-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2012-12-06 21:39                 ` Jeremy Allison
2012-12-07 14:29       ` Steve French
     [not found]         ` <CAH2r5msoPiu7wz-HjnnqTxeBLVEQiMYSnLMaZ+dEr11j6Fo4Ew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-07 14:30           ` Steve French
2012-12-07 16:34           ` Alan Cox
2012-12-07  9:08   ` Pavel Shilovsky
     [not found]     ` <CAKywueQ3d=wdq2nw5f-QS-D9PY70Axa3Cn0gi5GRk4Xso+iquA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-07 14:52       ` J. Bruce Fields
     [not found]         ` <20121207145206.GF17115-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2012-12-07 15:37           ` simo
2012-12-07 16:09             ` J. Bruce Fields
2012-12-07 16:16   ` Christoph Hellwig
     [not found]     ` <20121207161602.GA17710-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2012-12-07 20:43       ` Pavel Shilovsky
     [not found]         ` <495d17310e0a687d446afc86def0f058-Gr3b2bv8/haq3CaADJ+gRi8mxiWnj2XH@public.gmane.org>
2012-12-07 21:35           ` Alan Cox
2012-12-10 16:41           ` J. Bruce Fields
     [not found]             ` <20121210164116.GC13327-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2012-12-11 13:11               ` Jeff Layton [this message]
2012-12-07 23:55         ` Myklebust, Trond
2012-12-12  8:34         ` David Laight
     [not found]           ` <20121212083401.GW5010-y8aDsudeyGZKtrsfIrZdgrVCufUGDwFn@public.gmane.org>
2012-12-14 14:12             ` Pavel Shilovsky
     [not found]               ` <CAKywueSN++ZCNJ1zbET_axuwXd2ZujvSof9H82E3AdeZWY_BgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14 15:30                 ` Alan Cox
     [not found]                   ` <20121214153000.62af6cbc-38n7/U1jhRXW96NNrWNlrekiAK3p4hvP@public.gmane.org>
2012-12-14 19:19                     ` Steve French
     [not found]                       ` <CAH2r5muRyB2529EcQXFysrSDpMKe0m3JfiEc5929O6oTmG-ThQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-17 15:36                         ` J. Bruce Fields
  -- strict thread matches above, loose matches on Subject: below --
2012-11-21 14:25 Pavel Shilovsky
     [not found] ` <1353507930-10908-1-git-send-email-piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org>
2012-11-21 14:47   ` Pavel Shilovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121211081135.136ee0d0@tlielax.poochiereds.net \
    --to=jlayton-eunubhrolfbytjvyw6ydsg@public.gmane.org \
    --cc=bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org \
    --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org \
    --cc=wine-devel-5vRYHf7vrtgdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).