Hello,
I'm working on a new export option for labeled nfs and I'm getting some
really weird behavior out of exportfs. I reverted my work to see if it
was the cause of the problem however the error still persists. For a
while I was getting errors about exportfs not knowing about
no_all_squashlabelloc=key so I tried to fix that and in the process I'd
had managed to get it to ignore labelloc all together. I don't think
that is the cause of the problems though. When I cat /var/lib/nfs/etab I
get a really weird line.
/exports *(rw,sync,wdelay,security_label,hide,nocrossmnt,insecure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534,sec=unix,rw,root_squash,no_all_squash)
if you notice rw,root_squash, and no_all_squash are in that line twice.
I can't seem to figure out where the second set of those come from. I
believe that is causing the problem with my labelloc export because I
can't figure out how to get the last no_all_squash to have a comma after
it. It seems odd to me that this is doubled and I'm guessing it might be
a bug. I'm using the kernel and nfs-utils git hashes below.
Kernel: 22763c5cf3690a681551162c15d34d935308c8d7 (with LNFS patches)
nfs-utils: 1a1f991870f02b303a05e1d63915226e7cfb9f53 (with LNFS patches)
Dave
On Tue, Jan 19, 2010 at 03:32:10PM -0500, David P. Quigley wrote:
> Hello,
> I'm working on a new export option for labeled nfs and I'm getting some
> really weird behavior out of exportfs. I reverted my work to see if it
> was the cause of the problem however the error still persists. For a
> while I was getting errors about exportfs not knowing about
> no_all_squashlabelloc=key so I tried to fix that and in the process I'd
> had managed to get it to ignore labelloc all together. I don't think
> that is the cause of the problems though. When I cat /var/lib/nfs/etab I
> get a really weird line.
>
> /exports *(rw,sync,wdelay,security_label,hide,nocrossmnt,insecure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534,sec=unix,rw,root_squash,no_all_squash)
>
> if you notice rw,root_squash, and no_all_squash are in that line twice.
That's normal; it also allows some flags to vary on a
per-security-flavor basis, so that last bit:
sec=unix,rw,root_squash,no_all_squash
is just telling you what their values are for the specific sec=unix
case. It's redundant but harmless.
> I can't seem to figure out where the second set of those come from. I
> believe that is causing the problem with my labelloc export because I
> can't figure out how to get the last no_all_squash to have a comma after
> it.
Looks like you have to modify both support/nfs/exports.c:putexportent()
and utils/exportfs/exportfs.c:dump(), in addition to parseopts().
(Which is really confusing. Someone should fix that..) Maybe you're
forgetting one of those?
--b.
> It seems odd to me that this is doubled and I'm guessing it might be
> a bug. I'm using the kernel and nfs-utils git hashes below.
>
> Kernel: 22763c5cf3690a681551162c15d34d935308c8d7 (with LNFS patches)
> nfs-utils: 1a1f991870f02b303a05e1d63915226e7cfb9f53 (with LNFS patches)
>
> Dave
>
> _______________________________________________
> NFSv4 mailing list
> [email protected]
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Tue, 2010-01-19 at 15:48 -0500, J. Bruce Fields wrote:
> On Tue, Jan 19, 2010 at 03:32:10PM -0500, David P. Quigley wrote:
> > Hello,
> > I'm working on a new export option for labeled nfs and I'm getting some
> > really weird behavior out of exportfs. I reverted my work to see if it
> > was the cause of the problem however the error still persists. For a
> > while I was getting errors about exportfs not knowing about
> > no_all_squashlabelloc=key so I tried to fix that and in the process I'd
> > had managed to get it to ignore labelloc all together. I don't think
> > that is the cause of the problems though. When I cat /var/lib/nfs/etab I
> > get a really weird line.
> >
> > /exports *(rw,sync,wdelay,security_label,hide,nocrossmnt,insecure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534,sec=unix,rw,root_squash,no_all_squash)
> >
> > if you notice rw,root_squash, and no_all_squash are in that line twice.
>
> That's normal; it also allows some flags to vary on a
> per-security-flavor basis, so that last bit:
>
> sec=unix,rw,root_squash,no_all_squash
>
> is just telling you what their values are for the specific sec=unix
> case. It's redundant but harmless.
>
> > I can't seem to figure out where the second set of those come from. I
> > believe that is causing the problem with my labelloc export because I
> > can't figure out how to get the last no_all_squash to have a comma after
> > it.
>
> Looks like you have to modify both support/nfs/exports.c:putexportent()
> and utils/exportfs/exportfs.c:dump(), in addition to parseopts().
> (Which is really confusing. Someone should fix that..) Maybe you're
> forgetting one of those?
>
> --b.
I'm almost certain I am. I'll look over my patches again to take a look
at that. I also need to look over my update code for the kernel export
function because I was getting the labelloc entry in /var/lib/nfs/etab
on initial daemon start but subsequent exportfs options seem to make it
go away.
Thanks,
Dave
On Tue, Jan 19, 2010 at 03:59:33PM -0500, David P. Quigley wrote:
> On Tue, 2010-01-19 at 15:48 -0500, J. Bruce Fields wrote:
> > Looks like you have to modify both support/nfs/exports.c:putexportent()
> > and utils/exportfs/exportfs.c:dump(), in addition to parseopts().
> > (Which is really confusing. Someone should fix that..) Maybe you're
> > forgetting one of those?
> >
> > --b.
>
> I'm almost certain I am. I'll look over my patches again to take a look
> at that. I also need to look over my update code for the kernel export
> function because I was getting the labelloc entry in /var/lib/nfs/etab
> on initial daemon start but subsequent exportfs options seem to make it
> go away.
You might have been missing code to parse it or store it in an export,
so it got lost before it wrote the entry back out again? I don't know.
If you're feeling community-minded, that business with having two
entirely separate bits of code to write out an etab entry seems silly.
(Maybe there are two different formats, I'm forgetting, but if so
couldn't they at least share common code to lookup the string names of
the options?)
--b.