[Toybox] [PATCH] tar.test: fix the tests when run as root.

[Rob Landley]

On 9/1/22 18:00, enh via Toybox wrote:
> Afaik, I'm the only person regularly running the toybox tests as
> root (in Android's CI), so I haven't actually fixed the character
> special and block special tests for macOS here --- I've fixed them
> so they work again on Android and Linux, and am just assuming we'll
> "skipnot" them on macOS. The first person to want to run the tests
> as root on macOS can fix this more thoroughly.

I need to run the root tests more myself (part of what running the tests under
mkroot is supposed to allow). I'm trying to fix it to work with "sys" and...

-crw-rw---- 1 root sys 12,  34 1970-01-01 00:00 dir/char
+crw-rw-r-- 1 root sys 12, 34 Jan  1  1970 dir/char

Why would that change between root and non-root... because it didn't, devuan
changed the default format out from under me in a version "upgrade". (Yes, this
is more "make test_tar" without the rest of toybox, meaning it's not using
toybox ls, meaning your previous argument circles around again...)

I can force the time format with --full-time, although does the mac ls command
have that...

https://apple.stackexchange.com/questions/15170/how-do-i-change-the-time-format-used-by-ls-command-line-on-osx

No it does  not. Nor does it provide an obvious alternative, they recommend
"brew install coreutils". Right, I'm pretty happy saying mac only supports "make
tests" all at once with macos_defconfig, and if you want more than that you can
set up the $PATH to appropriate commands yourself. (Comparing toybox, busybox,
and debian makes sense. Comparing with macosx is out of scope.)

Except with --full-time it goes:

crw-rw---- 1 root sys 12, 34 1970-01-01 00:00:00.000000000 +0000 dir/char

Luckily we forced TZ=UTC but what if the underlying filesystem doesn't SUPPORT
nanoseconds? (Will it still display them? Are any filesystems that don't support
nanoseconds still a concern?)

Possibly toybox ls should support --time-format=long-iso (ahem: time-style)...
except, even then the spacing is off when I list /dev? Why is the spacing off?
Because a couple entries in /dev have:

crw-rw----+ 1 root    video    81,   0 2022-09-01 11:12 video0
crw-rw----+ 1 root    video    81,   1 2022-09-01 11:12 video1

What does the plus mean? I've never seen the plus before... Sigh:

https://en.wikipedia.org/wiki/File-system_permissions#:~:text=access%20control%20list

Debian does not have selinux enabled! Grrr. I'm guessing udevd has common rules
or something, not chasing it down right now and in any case "system it's running
on" can have arbitrary nuts spacing, so NOSPACE=1 the test. Does mksh support
prefix assignments on functions...

  $ mksh -c 'x() echo "$ABC"; ABC=def x'
  def

Yes it does. Right.

Alright, put all this together and:

-crw-rw---- 1 root sys 12, 34 1970-01-01 00:00:00.000000000 +0000 dir/char
+crw-rw-r-- 1 root sys 12, 34 1970-01-01 00:00:00.000000000 +0000 dir/char

The file creation permissions are still different. Your patch didn't change the
permissions? The umask 0002 is zapping o+w but not o+r...?

Ah, it's another "toybox" vs "debian du jour". Can coreutils please STOP
RANDOMLY CHANGING STUFF? Grrr. Luckily, mknod has -m. (Checking to see if macos'
mknod has -m, I find that macos does not appear to HAVE a command line mknod
utility, just the system call? Anyway: gestalt toybox testing there, yay.)

And a TODO item added to see if mknod's default permissions should change. (I.E.
track down when/why gnu/mknod changed.)

> Also use a consistent group as well as user for the "ownership"
> test.

Except it's "wheel" on the BSD-alikes, that change was made for a reason. Let's
see... teach "skipnot" to exit with true or false and have an && thingy on the
end to chgrp.

> With this patch, the tests still pass on Linux and macOS but also
> pass as root on Android.

I can't seem to fix the last one:

FAIL: tar ownership
echo -ne '' | tar c --owner root --group sys --mtime @1234567890 dir/file | SUM 3
--- expected	2022-09-04 09:11:48.899556402 +0000
+++ actual	2022-09-04 09:11:48.903556402 +0000
@@ -1 +1 @@
-2d7b96c7025987215f5a41f10eaa84311160afdb
+d9e7fb3884430d29e7eed0dc04a2593dd260df14

And alas I dunno what the difference IS, the downside of an opaque hash. (It's
consistently doing it with debian's tar and my tar so the file's got something
different. Deleting and recreating dir/file right before the test isn't changing
it...)

The problem is, if you're still seeing the OLD hash, I can't just change it to
the one I'm seeing. If you are, could you send me the tarball? (You saw the
"save all tarballs" hack a couple emails back, right? I should work the test
name in there or something, although "sha1sum *" should let you know which one
has the matching hash...)

I checked in the rest of it, lemme know what I broke?

Thanks,

Rob