From: Ismael Luceno <ismael@iodev.co.uk>
To: musl@lists.openwall.com
Subject: Re: [PATCH v2] glob: implement GLOB_TILDE
Date: Thu, 25 Jul 2019 12:33:33 +0200 [thread overview]
Message-ID: <20190725103333.GA30296@pirotess.home> (raw)
In-Reply-To: <20190725034814.GI1506@brightrain.aerifal.cx>
On 24/Jul/2019 23:48, Rich Felker wrote:
<...>
> > + char *p = *pat + 1;
> > + size_t i = 0;
> > +
> > + char *name_end = strchrnul(p, '/');
> > + if (*name_end) *name_end++ = 0;
> > + *pat = name_end;
> > +
> > + char *home = (*p || issetugid()) ? NULL : getenv("HOME");
>
> I still don't see any justification for violating the semantics of ~
> because the program is suid.
I could only find a couple of implementations which don't check for
privileges:
- 4.3BSD
+ NetBSD
- uClibc
+ uClibc-ng
Almost everyone else does:
- FreeBSD
+ MidnightBSD
+ DragonFlyBSD
+ Android (Bionic)
- GNU
- Newlib
- OpenBSD
+ MirBSD
- Solaris
+ Illumos
I think most users/software would expect it.
> Also, issetugid isn't in the namespace we can use here. Rather than
> poking directly at libc.secure, if we needed this I think it would be
> better to make a namespace-protected alias, but I don't think it's the
> right behavior anyway.
I would go with that.
> > + if (!home) {
> > + struct passwd pw, *res;
> > + switch (*p ? getpwnam_r(p, &pw, buf, PATH_MAX, &res)
> > + : getpwuid_r(getuid(), &pw, buf, PATH_MAX, &res)) {
>
> Same here. I'm not actually sure what should happen if $HOME is unset,
> but it's probably whatever the Shell Command Language specification
> says.
All the implementations I could find fall back to getpw*.
> > + default:
> > + return GLOB_ABORTED;
> > + case ERANGE: case ENOMEM:
> > + return GLOB_NOSPACE;
> > + case 0:
> > + if (!res) return GLOB_NOMATCH;
>
> The man page says:
>
> If the username is invalid, or the home directory cannot be
> determined, then no substitution is performed.
>
> and the glibc manual says:
>
> If the user name is not valid or the home directory cannot be
> determined for some reason the pattern is left untouched and
> itself used as the result
>
> So I think this should not be an error. I'm not entirely clear if it's
> supposed to suppress all further glob expansion and just return a
> single literal result, or treat "~" or "~nosuchuser" as a literal
> component and search it.
It's supposed to continue; but IMO that's neither intuitive nor safe.
I guess that's why glibc added GLOB_TILDE_CHECK, but it should be the
only possibility.
However, if you feel strongly about it, I can add _CHECK instead.
I think:
- ENOMEM should map to NOSPACE.
- a closer look reveals that all other errors should map to NOMATCH.
> > + }
> > + home = pw.pw_dir;
> > + }
> > + while (i < PATH_MAX - 2 && *home)
> > + buf[i++] = *home++;
>
> This could be strnlen+memmove, but perhaps just open coding it like
> you've done is simpler and lighter.
>
> > + if (i > PATH_MAX - 2)
>
> Off-by-one. If it stopped due to reaching the limit in the above loop,
> you'll have equality not greater-than, then overflow below. Perhaps
> strnlen+memmove would be easier to ensure the safety of.
No overflow:
i++ => PATH_MAX - 2
i => PATH_MAX - 1
> > + return GLOB_NOSPACE;
>
> GLOB_NOSPACE is for allocation errors.
Right.
> This is a no-match case, since there can be no matches for a pattern
> PATH_MAX or longer.
It must work for "~\0".
next prev parent reply other threads:[~2019-07-25 10:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-24 21:33 Ismael Luceno
2019-07-25 3:48 ` Rich Felker
2019-07-25 10:33 ` Ismael Luceno [this message]
2019-07-25 14:30 ` Rich Felker
2019-07-25 15:39 ` Ismael Luceno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190725103333.GA30296@pirotess.home \
--to=ismael@iodev.co.uk \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).