From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23243 invoked from network); 25 Nov 2020 19:40:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 25 Nov 2020 19:40:14 -0000 Received: (qmail 15734 invoked by uid 550); 25 Nov 2020 19:40:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15713 invoked from network); 25 Nov 2020 19:40:11 -0000 MIME-Version: 1.0 Date: Wed, 25 Nov 2020 22:40:00 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com In-Reply-To: <20201125150254.GG534@brightrain.aerifal.cx> References: <20201122225619.GR534@brightrain.aerifal.cx> <97dd3cf7c69673e5962e9ccd46ea5131@ispras.ru> <20201123031932.GS534@brightrain.aerifal.cx> <20201123185633.GY534@brightrain.aerifal.cx> <20201123205259.GZ534@brightrain.aerifal.cx> <48faf5ab9a1f3c869c85897217db0d75@ispras.ru> <20201124042646.GA534@brightrain.aerifal.cx> <20201124063048.GB534@brightrain.aerifal.cx> <20201125150254.GG534@brightrain.aerifal.cx> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <6e2036a5e242e3d0f5c076f3c3d23d45@ispras.ru> X-Sender: izbyshev@ispras.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] realpath without procfs -- should be ready for inclusion On 2020-11-25 18:02, Rich Felker wrote: > On Tue, Nov 24, 2020 at 12:21:36PM +0300, Alexey Izbyshev wrote: >> On 2020-11-24 09:30, Rich Felker wrote: >> >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: >> > >> Added some more ideas. >> >> >- Absolute argument starting with /, //, and /// >> - Absolute argument equal to one of /, //, and /// >> >- Absolute symlink target starting with /, //, and /// >> - Absolute symlink target equal to one of /, //, and ///, with the >> link separated from the following component with /, // >> >- Final / after symlink-to-dir, dir, symlink-to-nondir, nondir >> - Intermediate / after symlink-to-nondir, nondir >> >- Final / in link contents after [the above] >> - Multiple / after ., .., normal component >> >- 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 >> - . following symlink-to-dir, dir, symlink-to-nondir, nondir >> >- More .. than path depth >> >- Null argument >> >- Empty string argument >> - Argument consisting of a single ., .. >> >- 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 >> - Argument with PATH_MAX length (ENAMETOOLONG) >> - A relative symlink in the argument such that the length of the >> result is PATH_MAX-1 (valid path), PATH_MAX (ENAMETOOLONG) >> - An absolute symlink in the argument similar to the above >> - A relative argument with the current directory similar to the above >> - An argument consisting of a single (relative, absolute) symlink >> with the target having length PATH_MAX-1 >> - An argument ending with a relative symlink with the target having >> length PATH_MAX-1 (ENAMETOOLONG) >> - An argument ending with an absolute symlink with the target having >> length PATH_MAX-1 (valid path) > > OK, here are my WIP testcases. They only cover static cases, not > anything that depends on implementation-defined value of PATH_MAX or > how the working directory combines with tests to reach PATH_MAX. > > The way you run the tests is by running ../setup.sh then ../checker.sh > from a scratch subdir of the dir containing the test files (realpath.c > also needs to be compiled and linked against the realpath impl you > want to test) > > Format of the testcase file is one test per line, input and expected > output separated by whitespace. . and .. in expected output are > translated based on working dir. Error names are treated as output > since they don't fall in same namespace (no initial /). > > All tests are currently passing for me. > Tests pass for me too. For the previous procfs-based impl and for glibc realpath(), the set of failing tests is exactly the same (all tests for //): // -> / (expected //) //.. -> / (expected //) alt1 -> / (expected //) alt1/ -> / (expected //) alt1/. -> / (expected //) alt2 -> / (expected //) alt2/ -> / (expected //) alt2/. -> / (expected //) > If you have ideas for additional static tests that fit the form and > are easy to add, please suggest. > A test for ELOOP is easy to add. Some of the skipped tests of the initially proposed list also fall within "static tests" limitations, e.g.: * trailing . (could be added in the form of triples as existing tests for trailing / and ..) * initial .. (or .) in a symlink target * multiple / in the middle of the argument before a component that is not going to be removed Alexey