[PATCH] fix posix lock on NFS

[PATCH] fix posix lock on NFS

[ASANO Masahiro]

Hi,

I found a problem on NFS client code.  It enables a local user to
crash the system.

NFS client prevents mandatory lock, but there is a flaw on it; Locks
are possibly left if the mode is changed while locking.  And a recent
changes on VFS makes it calls BUG().

For example:
   fd = open("file_on_nfs", O_RDWR | O_CREAT, 0644);
   memset(&lck, 0, sizeof(lck));
   lck.l_type = F_WRLCK;
   fcntl(fd, F_SETLK, &lck);    // get locked
   fchmod(fd, 02644);           // change i_mode to -rw-r-Sr--
   close(fd);                   // "kernel BUG at fs/locks.c:1932!"

The cause is:
   o The situation that locking succeeds but unlocking fails is
     possible, because of i_mode.
   o locks_remove_flock() calls BUG() if posix locks remain on an
     inode when closing.  It was changed at 2.6.13-rc4.

Here is a patch against 2.6.15-rc6.  This permits unlocking even if
the mandatory lock bits are set.

Signed-off-by: ASANO Masahiro <masano@tnes.nec.co.jp>
---

--- linux-2.6.15-rc6/fs/nfs/file.c.orig	2005-12-21 21:30:14.000000000 +0900
+++ linux-2.6.15-rc6/fs/nfs/file.c	2005-12-21 21:42:16.000000000 +0900
@@ -524,7 +524,8 @@ static int nfs_lock(struct file *filp, i
 		return -EINVAL;
 
 	/* No mandatory locks over NFS */
-	if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
+	if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID &&
+	    fl->fl_type != F_UNLCK)
 		return -ENOLCK;
 
 	if (IS_GETLK(cmd))

Re: [PATCH] fix posix lock on NFS

[Peter Staubach]

ASANO Masahiro wrote:

>---
>
>--- linux-2.6.15-rc6/fs/nfs/file.c.orig	2005-12-21 21:30:14.000000000 +0900
>+++ linux-2.6.15-rc6/fs/nfs/file.c	2005-12-21 21:42:16.000000000 +0900
>@@ -524,7 +524,8 @@ static int nfs_lock(struct file *filp, i
> 		return -EINVAL;
> 
> 	/* No mandatory locks over NFS */
>-	if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
>+	if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID &&
>+	    fl->fl_type != F_UNLCK)
> 		return -ENOLCK;
> 
> 	if (IS_GETLK(cmd))
>

Just out of curiosity, what is this if() statement intended to protect?
For locking purposes, why would the client care if the file has the
mandatory lock bits set?

    Thanx...

       ps

Re: [PATCH] fix posix lock on NFS

[Matthew Wilcox]

On Tue, Jan 03, 2006 at 02:39:24PM -0500, Peter Staubach wrote:
> >	/* No mandatory locks over NFS */
> >-	if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
> >+	if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID &&
> >+	    fl->fl_type != F_UNLCK)
> 
> Just out of curiosity, what is this if() statement intended to protect?
> For locking purposes, why would the client care if the file has the
> mandatory lock bits set?

Mandatory locks aren't mandatory for other clients.

Re: [PATCH] fix posix lock on NFS

[Peter Staubach]

Matthew Wilcox wrote:

>On Tue, Jan 03, 2006 at 02:39:24PM -0500, Peter Staubach wrote:
>  
>
>>>	/* No mandatory locks over NFS */
>>>-	if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
>>>+	if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID &&
>>>+	    fl->fl_type != F_UNLCK)
>>>      
>>>
>>Just out of curiosity, what is this if() statement intended to protect?
>>For locking purposes, why would the client care if the file has the
>>mandatory lock bits set?
>>    
>>
>
>Mandatory locks aren't mandatory for other clients.
>  
>

So?

I guess that I don't understand this response.

The server is responsible for keeping itself from attempting to access
a mandatory lock file.  The client is not responsible for doing so and
trying to help the server is kind of a waste of time, mostly.

The mandatory lock mode bits really only come into play when attempting
to read or write the file.  In this case, the system will automatically
try to take a lock for the process, if that process does not already
have a lock.  The server should prevent itself from trying to access
files like this in order to avoid DoS attacks.

The NFS client does not support mandatory locking, mostly due to the
possibility of DoS attacks and also due to the locking and NFS protocols
not being sufficiently aware of each other.  NFSv4 can be used to address
this latter problem, but probably not the former.

So, why deny lock requests for such files?  Especially on the client?

    Thanx...

       ps

Re: [PATCH] fix posix lock on NFS

[Trond Myklebust]

On Tue, 2006-01-03 at 15:09 -0500, Peter Staubach wrote:
> Matthew Wilcox wrote:
> >Mandatory locks aren't mandatory for other clients.
> >  
> >
> 
> So?
> 
> I guess that I don't understand this response.
> 
> The server is responsible for keeping itself from attempting to access
> a mandatory lock file.  The client is not responsible for doing so and
> trying to help the server is kind of a waste of time, mostly.
> 
> The mandatory lock mode bits really only come into play when attempting
> to read or write the file.  In this case, the system will automatically
> try to take a lock for the process, if that process does not already
> have a lock.  The server should prevent itself from trying to access
> files like this in order to avoid DoS attacks.
> 
> The NFS client does not support mandatory locking, mostly due to the
> possibility of DoS attacks and also due to the locking and NFS protocols
> not being sufficiently aware of each other.  NFSv4 can be used to address
> this latter problem, but probably not the former.
> 
> So, why deny lock requests for such files?  Especially on the client?

I agree, however that would have been a change in behaviour that would
have been hard to find time to test properly in an -rc6(?) release, so
we went for the quick and dirty fix.

Cheers,
  Trond

Re: [PATCH] fix posix lock on NFS

[Peter Staubach]

Trond Myklebust wrote:

>On Tue, 2006-01-03 at 15:09 -0500, Peter Staubach wrote:
>  
>
>>Matthew Wilcox wrote:
>>    
>>
>>>Mandatory locks aren't mandatory for other clients.
>>> 
>>>
>>>      
>>>
>>So?
>>
>>I guess that I don't understand this response.
>>
>>The server is responsible for keeping itself from attempting to access
>>a mandatory lock file.  The client is not responsible for doing so and
>>trying to help the server is kind of a waste of time, mostly.
>>
>>The mandatory lock mode bits really only come into play when attempting
>>to read or write the file.  In this case, the system will automatically
>>try to take a lock for the process, if that process does not already
>>have a lock.  The server should prevent itself from trying to access
>>files like this in order to avoid DoS attacks.
>>
>>The NFS client does not support mandatory locking, mostly due to the
>>possibility of DoS attacks and also due to the locking and NFS protocols
>>not being sufficiently aware of each other.  NFSv4 can be used to address
>>this latter problem, but probably not the former.
>>
>>So, why deny lock requests for such files?  Especially on the client?
>>    
>>
>
>I agree, however that would have been a change in behaviour that would
>have been hard to find time to test properly in an -rc6(?) release, so
>we went for the quick and dirty fix.
>

Okay.

Are we going to be able to fix this properly once things open up a bit then?

    Thanx...

       ps