[PATCH 12/16] nfsd4: make readonly access depend on pseudoflavor
J. Bruce Fields
bfields at fieldses.org
Mon Jun 18 11:59:42 EDT 2007
On Tue, May 22, 2007 at 05:00:57PM +1000, Neil Brown wrote:
> On Friday May 18, bfields at fieldses.org wrote:
> > From: J. Bruce Fields <bfields at citi.umich.edu>
> >
> > Allow readonly access to vary depending on the pseudoflavor, using the
> > flag passed with each pseudoflavor in the export downcall. The rest of
> ^^^^^^^^^^^
> > the flags are ignored for now, though some day we might also allow id
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > squashing to vary based on the flavor.
>
> This begs the question: Should we allow those flags to be set.
>
> i.e. if a per-pseudoflavour flag is set that we don't support,
> should we just return an error so that the admin knows that their
> configuration is not supported.
> And how do you tell if a flag is set or not...
> Maybe we should complain if the per-pseudoflavour flags are different
> to the export-wide flags on any bit other than readonly?
That makes sense to me; done.
> Different id squashing? Maybe, but it would be awkward to squash to a
> different id. I suspect there would be no call for that. But having
> different values for the allsquash and rootsquash flags might make
> sense one day.
Yes, so I've gone ahead and implemented that.
I also took a quick look at local Solaris and NetApp documentation, and
found that the flags they allow to vary per-flavor are essentially the
same (ro and id-squashing flags).
I've also added support for secinfo to the nfsd.export cache show
method and fixed exp_find and friends (as discussed before). My most
recent patch series is available from the server-secinfo branch at
git://linux-nfs.org/~bfields/linux.git server-secinfo
Let me know when/if you'd like another mailbomb. (It's 20 patches at
this point.)
--b.
More information about the NFSv4
mailing list