rpc.mountd and character class matches

rpc.mountd and character class matches

[Jeff Layton]

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.

If we do want to keep it, what's the behavior we should be shooting for
here?

Thoughts?
-- 
Jeff Layton <jlayton@redhat.com>

Re: rpc.mountd and character class matches

[J. Bruce Fields]

On Tue, Jun 21, 2011 at 11:26:45AM -0400, Jeff Layton 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.

If it's complicated, likely buggy code, and we can't find any evidence
that anyone uses it, let's toss it.  Hard to imagine anyone will
complain, but if they do, at least they may be able to help us answer
this question:

> If we do want to keep it, what's the behavior we should be shooting for
> here?

--b.

Re: rpc.mountd and character class matches

[NeilBrown]

On Tue, 21 Jun 2011 11:26:45 -0400 Jeff Layton <jlayton@redhat.com> 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

NeilBrown

Re: rpc.mountd and character class matches

[Jeff Layton]

On Wed, 22 Jun 2011 08:33:44 +1000
NeilBrown <neilb@suse.de> wrote:

> On Tue, 21 Jun 2011 11:26:45 -0400 Jeff Layton <jlayton@redhat.com> 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@redhat.com>