NetBSD Problem Report #59155

From www@netbsd.org  Sun Mar  9 03:23:21 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C531C1A923C
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  9 Mar 2025 03:23:20 +0000 (UTC)
Message-Id: <20250309032319.93B9D1A923E@mollari.NetBSD.org>
Date: Sun,  9 Mar 2025 03:23:19 +0000 (UTC)
From: thorpej@me.com
Reply-To: thorpej@me.com
To: gnats-bugs@NetBSD.org
Subject: bin/sh/t_input:nul_elimination, possibly other sh tests, require root for silly reasons
X-Send-Pr-Version: www-1.0

>Number:         59155
>Notify-List:    riastradh@NetBSD.org
>Category:       misc
>Synopsis:       bin/sh/t_input:nul_elimination, possibly other sh tests, require root for silly reasons
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kre
>State:          feedback
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 09 03:25:00 +0000 2025
>Closed-Date:    
>Last-Modified:  Mon Mar 10 00:05:01 +0000 2025
>Originator:     Jason Thorpe
>Release:        NetBSD 10.1
>Organization:
RISCy Business
>Environment:
NetBSD avanti.ktnet 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/alpha/compile/GENERIC alpha

hw.model = AlphaStation 200 4/233
>Description:
After running a full test suite pass on a non-emulated Alpha, I noticed some shell test failures.  In the case of bin/sh/t_input:nul_elimination, it seems to be because it wants to create a file called "helper.sh" in the current working directory.  This failed because I did not run the tests as root.

The test suite was run by performing the following commands as a non-root user:

cd /usr/tests
atf-run | atf-report

>How-To-Repeat:
cd /usr/tests/bin/sh
./t_input nul_elimination


>Fix:
Not provided.

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sun, 09 Mar 2025 14:00:59 +0000
State-Changed-Why:
Does this reproduce if you use `atf-run t_input'?

Normally, atf-run creates a temporary directory which the test can
write into.  If you don't use atf-run, you are responsible for
creating a temporary directory and chdiring into it when you run the
test, e.g.:

mkdir /tmp/test
cd /tmp/test
/usr/tests/bin/sh/t_input nul_elimination

It would be nice if there were a way to ask atf-run to run a single
test case by name, but we don't have that as far as I know.


From: Jason Thorpe <thorpej@me.com>
To: gnats-bugs@netbsd.org
Cc: misc-bug-people@netbsd.org,
 netbsd-bugs@netbsd.org,
 gnats-admin@netbsd.org,
 Taylor Campbell <riastradh@NetBSD.org>
Subject: Re: misc/59155 (bin/sh/t_input:nul_elimination, possibly other sh
 tests, require root for silly reasons)
Date: Sun, 9 Mar 2025 08:10:11 -0700

 > On Mar 9, 2025, at 7:00=E2=80=AFAM, riastradh@netbsd.org =
 <riastradh@NetBSD.org> wrote:
 >=20
 > Synopsis: bin/sh/t_input:nul_elimination, possibly other sh tests, =
 require root for silly reasons
 >=20
 > State-Changed-From-To: open->feedback
 > State-Changed-By: riastradh@NetBSD.org
 > State-Changed-When: Sun, 09 Mar 2025 14:00:59 +0000
 > State-Changed-Why:
 > Does this reproduce if you use `atf-run t_input'?
 >=20
 > Normally, atf-run creates a temporary directory which the test can
 > write into.  If you don't use atf-run, you are responsible for
 > creating a temporary directory and chdiring into it when you run the
 > test, e.g.:

 The original failure **was** with atf-run.  As noted in the report, the =
 original failures occurred with:

      cd /usr/tests
      atf-run | atf-report

 (atf-run not run as root.)

 -- thorpej

State-Changed-From-To: feedback->open
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sun, 09 Mar 2025 18:04:00 +0000
State-Changed-Why:
feedback provided


State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sun, 09 Mar 2025 18:04:39 +0000
State-Changed-Why:
I can't reproduce this.  Can you share the complete output of:

cd /usr/tests/bin/sh && atf-run t_input

when executed as a non-root user?


Responsible-Changed-From-To: misc-bug-people->kre
Responsible-Changed-By: kre@NetBSD.org
Responsible-Changed-When: Sun, 09 Mar 2025 20:56:53 +0000
Responsible-Changed-Why:
I am looking into this PR


From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/59155 (bin/sh/t_input:nul_elimination, possibly other sh tests, require root for silly reasons)
Date: Mon, 10 Mar 2025 04:14:57 +0700

 Jason, can you demonstrate how you ran the test, along with
 permissions, owners, etc, on any directories you consider
 relevant.

 It would also be mildly interesting to understand your interest
 in running a test which is currently broken (by sh updates) and
 which I have yet to take the time to work out what to do about.
 Though I guess that perhaps it is still intended to work in -10.

 (Most probably the whole test will simply be dropped, and replaced
 by one which verifies that \0 chars are treated as errors, but
 that test took quite a bit of effort to generate to make sure
 representatives of just about all the weird places a \0 might
 appear, and make sure they were all being ignored, that I kind
 of hate to lose it!)

   | Normally, atf-run creates a temporary directory which the test can
   | write into.

 Yes.

   | mkdir /tmp/test
   | cd /tmp/test
   | /usr/tests/bin/sh/t_input nul_elimination

 That would be an ugly way to run any ATF test.

   | It would be nice if there were a way to ask atf-run to run a single
   | test case by name, but we don't have that as far as I know.

 You mean like:

 jacaranda$ atf-run t_input:nul_elimination | atf-report
 Tests root: /home/kre/src/sh-tests

 t_input (1/1): 1 test cases
     nul_elimination: [2.521333s] Failed: Test case was expecting a failure but none were raised
 [2.521638s]

 Failed test cases:
     t_input:nul_elimination

 Summary for 1 test programs:
     0 passed test cases.
     1 failed test cases.
     0 expected failed test cases.
     0 skipped test cases.
 jacaranda$ TEST_SH=~/src/shells/sh-current/sh atf-run t_input:nul_elimination | atf-report
 Tests root: /home/kre/src/sh-tests

 t_input (1/1): 1 test cases
     nul_elimination: [0.078432s] Expected failure: nuls are now errors, not ignored, revisit later: atf-check failed; see the output of the test for details
 [0.078789s]

 Test cases for known bugs:
     t_input:nul_elimination: nuls are now errors, not ignored, revisit later: atf-check failed;
                              see the output of the test for details

 Summary for 1 test programs:
     0 passed test cases.
     0 failed test cases.
     1 expected failed test cases.
     0 skipped test cases.

 The first of those used my /bin/sh which is kind of ancient (pre 10
 branch), and so failed, because it failed to fail, the second used
 the same sh as is /bin/sh in HEAD, and so successfully failed as expected.

 kre


From: Robert Elz <kre@munnari.OZ.AU>
To: Jason Thorpe <thorpej@me.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: misc/59155 (bin/sh/t_input:nul_elimination, possibly other sh tests, require root for silly reasons)
Date: Mon, 10 Mar 2025 07:01:31 +0700

     Date:        Sun, 9 Mar 2025 15:06:57 -0700
     From:        Jason Thorpe <thorpej@me.com>
     Message-ID:  <C8A752C7-9B3C-4288-B697-F59C9AF25EA5@me.com>

   | I did a baseline run of the full test suite on a fresh NetBSD 10.1
   | install on an AlphaStation 200.  I ran it by logging in as user
   | “thorpej” and doing:
   |
   | $ cd /usr/tests
   | $ atf-run | atf-report
   |
   | …and then I let it run for like 2 days (because that’s how long it took).

 Yes, a full test run can take a long time, even on modern fast processors.

   | And at the end I had a the following list of failures:

   | Failed test cases:

 I'm not going to comment on the others at the minute (but some of the
 available tests are truly just broken, and when they work it is often
 just by chance, even if that seems to happen every time) but of these
 three:

   |    bin/sh/t_input:nul_elimination,
   |    bin/sh/t_patterns:filename_expansion,
   |    bin/sh/t_syntax:g_variable_syntax,

 the first two could be related to the inability to create files,
 the third cannot, all it is doing is setting and testing various
 shell variables (some of them with very long names).

 Can you do as Taylor asked (this should not run for more than a
 few seconds, even on a small alpha) and do

 	cd /usr/tests/bin/sh
 	atf-run t_input:nul_elimination

 and save the output, and send that here.   And then (as t_input is
 just a sh script) if there still looks to be a problem with creating
 helper.sh, edit it (the "binary") and just before the cat >helper.sh <<...
 insert

 	pwd
 	ls -ld .

 and run it again (and send the output from that).   You could also
 run t_syntax:g_variable_syntax in a similar way, and if that is
 still failing then run it again as

 	TEST_SH='/bin/sh -X' atf-run t_syntax:g_variable_syntax

 and send the output from that, so I can see what is happening (if
 you're using csh, or tcsh, or similar, stick "env" in front of that).

 The filename_expansion test is one of the slowest sh tests (ignoring
 those which are slow because they sleep for one reason or another)
 as it creates lots of files and directories, so I'd hold off on
 looking to see what it is doing until we work out what looks to be
 wrong with the others.

 kre

 ps: most of the traceme* failures will be duplicates of each other.
 I tried to convince Kamil (when he was adding all of that) to only
 do all the tests of the wait*() functions for the 2 that are actually
 system calls, and beyond that just test that the others map into the
 underlying sys call correctly, but he wouldn't...


>Unformatted:

Home	PR Database Search