Re: [musl] [PATCH musl v2 3/3] mntent: fix parsing lines with optional fields

[Rich Felker <dalias@libc.org>]

On Thu, May 12, 2022 at 09:58:30PM +0100, Oliver Ford wrote:
> On Thu, May 12, 2022 at 3:08 PM Rich Felker <dalias@libc.org> wrote:
> >
> > - There's also an independent bug in hasmntent that was reported a
> >   long time ago then lost: it will return false positives when one
> >   mntopt name is a substring of another. strstr is just not the right
> >   operation here, at least not without added logic to ensure matching
> >   on a whole option boundary. This is a separate issue that calls for
> >   a separate patch though, not a blocker on the patch under discussion
> >   here.
> >
> Looking at this, the "hasmntopt" function does match options where the
> string is part of the option but not the whole option. So the opt "ro"
> will correctly match the "ro" (for read-only) option, but also match
> an option that contains "symlinkroot".
> 
> The following version of the function keeps the initial strstr, but
> adds an extra check so that it doesn't match unless the next character
> is either a comma or nul. If there's no other special cases we need to
> handle, I'll submit as a
> patch?
> 
> char *hasmntopt(const struct mntent *mnt, const char *opt)
> {
>         char *op = strstr(mnt->mnt_opts, opt);
> 
>         if (op == NULL) return NULL;
>         size_t len = strlen(opt);
>         char *end = op + len;
>         if (*end == '\0' || *end == ',') return op;
> 
>         return NULL;
> }

This fails to check that the match is at the start of an option
(preceded by a ',' or at the beginning of string) and fails to
continue if the first match is a false positive (e.g. "ro" in
"symlinkroot,ro"). It's possible to solve this still using strstr in a
loop, but it might be easier to just iterate delimiters and strcmp.

Also, I'm not sure if hasmntopt is supposed to return a match or not
for something like "uid" in "uid=1001"; if so, being followed by '='
also needs to be considered valid match.

Rich