On Wed, 22 Jun 2011 08:33:44 +1000
NeilBrown <neilb@xxxxxxx> wrote:
> On Tue, 21 Jun 2011 11:26:45 -0400 Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>
> > I was writing up the manpage update for exports to include info about
> > IPv6 addressing, and made a mistake on my first pass. I put the IPv6
> > address in brackets. It turned out that this worked because mountd
> > treats stuff in brackets as a character class wildcard match.
> >
> > This behavior is undocumented in the manpage and it doesn't seem to
> > work correctly, but it's hard to be sure as I'm not sure what correct
> > behavior is for this.
> >
> > For instance, I have a host with a valid hostname (tlielax) in DNS on
> > my subnet, and when I put this in /etc/exports:
> >
> > /export [whiskeytangofoxtrot](rw)
> >
> > ...mountd allowed me to mount that. Normally a character class like
> > that should only match if you had a single-character hostname that
> > matches one of the characters in the brackets.
> >
> > My question is -- do we want to continue to allow this sort of wildcard
> > match in mountd? Given that it's not documented, it's hard to imagine
> > anyone relying on it.
>
> No, it isn't documented. But the documentation does talk about
> 'wildcards' (though it only mentions '*' and '?') and [foo] is often a valid
> wildcard, so people could try to use it and if they find that it works...
>
> I tried your example and it didn't work for me. I could not (from 'notabene')
> mount
> /home [whiskeytangofoxtrot](rw,no_root_squash,async,no_subtree_check)
>
> or
> /home [notabene](rw,no_root_squash,async,no_subtree_check)
>
> but I could mount
>
> /home [notabene]*(rw,no_root_squash,async,no_subtree_check)
>
> and looking at the code (in support/nfs/wildmat.c) I cannot see how your
> pattern would match anything other than a single character hostname...
>
> You did of course run "exportfs -r" after changing /etc/exports....
>
> >
> > If we do want to keep it, what's the behavior we should be shooting for
> > here?
> >
> > Thoughts?
>
> I think we should leave the current functionality in place (once we confirm
> that it works correctly as I think it does), possibly document it, but if the
> hostname looked like an IPv6 address in [], then special case that in much
> the same way that we special-case IP address.
> ie. 192.168.1.2 is a /32 subnetmask
> one.nine.one.two is a host name
>
I was pretty sure that I did that before, but I think you're correct
that I must have made a mistake in testing. I redid the above test and
it didn't allow me to mount. I also did some investigation and figured
out why having this was making it behave strangely:
https://bugzilla.redhat.com/show_bug.cgi?id=714977#c4
I also played around with the test program in wildmat.c and I think the
character class matches are working as intended. Given that I don't see
any need to rip the code out, but I think we probably should document
it. I'll roll up a patch to do that soon.
I think with that, I don't really see any need to special case IPv6
addresses inside brackets. There's really no reason to use brackets
around them in /etc/exports as it doesn't use ':' as a delimiter. When
I do the patch to document character class wildcards, I'll also add a
note to the parts about IPv6 addresses and mention that brackets should
not be used around them in /etc/exports.
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
