Neil Brown wrote:
> st_mode=S_IFREG|S_ISGID|0640 implies a "mandatory locking" file.
> knfsd currently refuses to touch mandatory locking files as NFS (v2
> and v3 at least) cannot support mandatory locking. It would probably
> be as safe, and less intrusive, to allow access but simply deny all
> lock requests to a mandatory locking file, but I haven't looked into
> the issues very deeply.
>
> Do you know which file is being accessed? used "tcpdump -s 300"
> should help you find out.
> Does it "need" to have mandatory locking set?
>
> NeilBrown
I ran into this one only a week ago here at VaLinux.
We encountered a file with that "magic" mode, but it wasn't intended for mandatory
locking. After a bit of research, I discovered that mandatory locking is now an
OPTION on local filesystems, and is DISABLED by default. There is a macro
'IS_MANDLOCK(inode)' (in include/linux/fs.h) which tests whether mandatory locking
is actually enabled on the filesystem. So the fix was to include this in the test
which nfsd uses to decide if a file may have mandatory locks.
In other words, the IS_ISMNDLK() macro in fs/nfsd/vfs.c expands to now become:
#define IS_ISMNDLK(i) (IS_MANDLOCK((i)) && \
(((i)->i_mode & (S_ISGID|S_IXGRP|S_IFMT)) \
== (S_ISGID|S_IFREG)))
This should take care of all normal cases. Of course, if for some reason the
server's filesystem is mounted with mandatory locking enabled, it'll still deny
access. However, mandatory locking is strongly deprecated these days, and I doubt
if more than a handful of people use the mount option to turn it on....
Hope this helps,
Dave Higgen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:12 EST