mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Alexey Izbyshev <izbyshev@ispras.ru>
Cc: musl@lists.openwall.com
Subject: Re: [musl] realpath without procfs -- should be ready for inclusion
Date: Tue, 24 Nov 2020 01:30:49 -0500	[thread overview]
Message-ID: <20201124063048.GB534@brightrain.aerifal.cx> (raw)
In-Reply-To: <a1c03f990da24f772689237ee8fdae38@ispras.ru>

On Tue, Nov 24, 2020 at 08:13:56AM +0300, Alexey Izbyshev wrote:
> On 2020-11-24 07:26, Rich Felker wrote:
> >On Tue, Nov 24, 2020 at 06:39:59AM +0300, Alexey Izbyshev wrote:
> >>On 2020-11-23 23:53, Rich Felker wrote:
> >>>On Mon, Nov 23, 2020 at 01:56:33PM -0500, Rich Felker wrote:
> >>>>On Sun, Nov 22, 2020 at 10:19:33PM -0500, Rich Felker wrote:
> >>>>--- realpath8.c	2020-11-22 17:52:17.586481571 -0500
> >>>>+++ realpath9.c	2020-11-23 13:55:06.808458893 -0500
> >>>>@@ -19,7 +19,7 @@
> >>>> 	char *output = resolved ? resolved : buf;
> >>>> 	size_t p, q, l, cnt=0;
> >>>>
> >>>>-	l = strnlen(filename, sizeof stack + 1);
> >>>>+	l = strnlen(filename, sizeof stack);
> >>>> 	if (!l) {
> >>>> 		errno = ENOENT;
> >>>> 		return 0;
> >>>>@@ -80,11 +80,16 @@
> >>>> 			return 0;
> >>>> 		}
> >>>> 		if (k==p) goto toolong;
> >>>>+		if (!k) {
> >>>>+			errno = ENOENT;
> >>>>+			return 0;
> >>>>+		}
> >>>> 		if (++cnt == SYMLOOP_MAX) {
> >>>> 			errno = ELOOP;
> >>>> 			return 0;
> >>>> 		}
> >>>> 		p -= k;
> >>>>+		if (stack[k-1]=='/') p++;
> >>>> 		memmove(stack+p, stack, k);
> >>>
> >>>This is wrong and needs further consideration.
> >>>
> >>Yes, now memmove() overwrites NUL if p was at the end and stack[k-1]
> >>== '/'. Is it true per POSIX that "rr/home" must resolve to "//home"
> >>if "rr" -> "//"?
> >
> >I don't think // is even required be distinct from /, just permitted,
> >but I think allowing it in userspace and handling it consistently is
> >the right behavior in case you ever run on a kernel that does make use
> >of the distinction.
> >
> >>If so, maybe something like the following instead:
> >>
> >>+               while (stack[p] == '/') p++;
> >>+               if (stack[p] && stack[k-1] != '/') p--;
> >>                p -= k;
> >>-               if (stack[k-1]=='/') p++;
> >
> >Rather just:
> >
> >	/* If link contents end in /, strip any slashes already on
> >	 * stack to avoid /->// or //->/// or spurious toolong. */
> >	if (stack[k-1]=='/') while (stack[p]=='/') p++;
> >
> >should work (before the p-=k;)
> >
> Yes, that looks good.
> 
> >>I've also noticed other issues to be fixed, per POSIX:
> >>
> >>* ENOENT should be returned if filename is NULL
> >
> >Rather it looks like it's:
> >
> >	[EINVAL] The file_name argument is a null pointer.
> >
> >ENOENT is only for empty string or ENOENT somewhere in the path
> >traversal process.
> >
> Uh, yes, that was bad copy-paste or something.
> 
> >>* ENOTDIR should be returned if the last component is not a
> >>directory  and the path has one or more trailing slashes
> >
> >Yes, that's precisely what I've been working on the past couple hours.
> >I think you missed but .. will also erase a path component that's not
> >a dir (e.g. /dev/null/.. -> /dev) and these are both instances of a
> >common problem. I thought use of readlink covered all the ENOTDIR
> >cases but it doesn't when the next component isn't covered by readlink
> >or isn't present at all.
> >
> Yes, initially I forgot about this whole ENOTDIR issue completely,
> and after noticing the problem with the last component, didn't look
> further.

I think before this goes upstream we should have a good set of
testcases that can be contributed to libc-test. Do you have ideas for
coverage? Some that come to mind:

- Absolute argument starting with /, //, and ///
- Absolute symlink target starting with /, //, and ///
- Final / after symlink-to-dir, dir, symlink-to-nondir, nondir
- Final / in link contents after [the above]
- Initial .. in argument, cwd root or non-root
- Initial .. in symlink target, symlink in root or non-root
- Initial ...
- .. following symlink-to-dir, dir, symlink-to-nondir, nondir
- More .. than path depth
- Null argument
- Empty string argument
- Empty string link contents (testable only with seccomp hack)
- Argument valid abs path exact length PATH_MAX-1
- Argument valid rel path exact length PATH_MAX-1 to short abs path

Some of these require namespace gymnastics to set up without running
the tests as root.

Rich

  reply	other threads:[~2020-11-24  6:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-22 22:56 Rich Felker
2020-11-23  2:03 ` Alexey Izbyshev
2020-11-23  3:17   ` Érico Nogueira
2020-11-23  3:34     ` Rich Felker
2020-11-23  3:19   ` Rich Felker
2020-11-23 18:56     ` Rich Felker
2020-11-23 20:53       ` Rich Felker
2020-11-24  3:39         ` Alexey Izbyshev
2020-11-24  4:26           ` Rich Felker
2020-11-24  5:13             ` Alexey Izbyshev
2020-11-24  6:30               ` Rich Felker [this message]
2020-11-24  9:21                 ` Alexey Izbyshev
2020-11-24 14:35                   ` Rich Felker
2020-11-24 20:17                     ` Rich Felker
2020-11-25 15:02                   ` Rich Felker
2020-11-25 19:40                     ` Alexey Izbyshev
2020-11-24 20:31             ` Rich Felker
2020-11-25  5:40               ` Alexey Izbyshev
2020-11-25 15:03                 ` Rich Felker
2020-11-24  3:41     ` Alexey Izbyshev

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=20201124063048.GB534@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=izbyshev@ispras.ru \
    --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).