>>>Robert Dinse said:
>
> We recently switched a mail server from userland nfsd to kernel nfsd in
> order to provide file locking and prevent corruption of mailboxes that was
> occuring when multiple servers attempted to update a mailbox simultaneously.
What version of the kernel are you using?
Are there any messages in your logfiles like:
fh_verify: no root_squashed access.
>
> We've run into some very strange behavioral problems with knfsd relative
> to userland nfsd.
>
> Particularly, we have a directory, /var/smartlist with a bunch of
> subdirectories for each mail list. The directory and subdirectories are owned
> by smartlst.smartlist with modes 771.
>
> This directory resides on the Linux server with knfsd, (formerly userland
> nfsd) and is exported to other mail servers and a shell server which happens to
> be running SunOS 4.1.4.
>
> Inside the list subdirectories are various smartlist files owned by users
> such as the 'dist' (distribution) file. With the userland nfsd, users on the
> shell server could edit their files in the smartlist subdirectories.
>
> When we upgraded to knfsd, the user can no longer modify files that exist
> in the directory even though they have write permission to those files and the
> files already exist. This is really broken and requires that we change the
> ownership of the subdirectories to the user to make this work. This is
> something we don't want to do as we don't want the user removing other files in
> the directory.
>
> Was this behavioral change intentional or just a screw-up? And if it is
> intentional, what logic dictated that permissions should work differently under
> NFS than they do on a local file system?
Unless the NFSEXP_NOSUBTREECHECK flag is set the only difference in the semantics
is that you can't accesss an open file unless you can open that file. That is that
with knfsd the file is opened with each access using the full path from the export
point.
Becuase of this you can't do:
file = fopen("test", "r");
chmod(".", 000);
fgets(buffer, 1024, file);
The read will fail with a
nfsd Security: %s/%s bad export
or
fh_verify: no root_squashed access.
message being put in your logfile.
If the NFSEXP_NOSUBTREECHECK flag is set then the semantics
should be the same for local and NFS access.
---------------------------------
G. Allen Morris III
-
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 May 15 2000 - 21:00:14 EST