On Tue, 9 May 2000, G. Allen Morris III wrote:
>
> What version of the kernel are you using?
2.2.15
> Are there any messages in your logfiles like:
>
> fh_verify: no root_squashed access.
No, and I did try no_root_squash in the export options to see if somehow
root_squash was an issue, it made no difference.
> >
> > 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.
Nope, this isn't it. You can open the file for read but not for write,
unless the parent directory is also writable.
-
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:15 EST