[Toybox] ASan freaks out when using tsort in multicall binaries

[Rob Landley]

On 10/7/23 00:35, Oliver Webb wrote:
>> Is it the "touch" that fails, or tar? Because the test is doing:
> 
> Putting a ' || echo "whatever" ' after the touch command that creates the long filenames shows nothing, 
> these are the logs from the test failure:
> 
> ln: failed to create symbolic link 'dir/[250 CHAR FILENAME (starts with 6)]' -> '[255 CHAR FILENAME (starts with 1)]': File name too long
> tar: dir/[250 CHARACTER FILENAME (starts with 6)]: File name too long
> tar: had errors
> FAIL: tar create long->long

Aha, that's a different test. That's doing:

  ln -s $LONG dir/${LONG:5}
  testing "create long->long" "$TAR dir/${LONG:5} | SUM 7" \
    "b9e24f53e27496c5125445230d201b4a36ff7398\n" "" ""

And the ln call before tar is failing, which on ext4 does:

$ LONG=0123456789abcdef0123456789abcdef
$ LONG=$LONG$LONG$LONG$LONG$LONG$LONG$LONG$LONG
$ LONG=${LONG:1:255}
$ mkdir dir
$ ln -s $LONG dir/${LONG:5}
$ ls -l dir
total 4
lrwxrwxrwx 1 landley landley 255 Oct  8 00:58
6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345
6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345
6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345
6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef ->
123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

(I had mercy and manually wordwrapped that last bit.)

And in fact:

$ touch dir/$(readlink dir/*)
landley at driftwood:~/toybox/toybox/subb$ ls -l dir
total 4
-rw-r--r-- 1 landley landley   0 Oct  8 01:02
123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

But the thing is, it's not saying _link_ too long. A link can be a path, or an
arbitrary string, it's not policed by the filesystem until you try to resolve it:

$ ln -s "$(seq 1 1000 | xargs)" dir/potato
$ ls dir/potato
ls: cannot access 'dir/potato': File name too long
$ ls -ld dir/potato | wc
      1    1010    3954

It's saying the _filename_ that ln is trying to create is too long. I.E. it's
not that ecryptfs can't handle a filename of length 255, it can't handle one of
length 250. What is the maximum...

https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs

Filenames expand during encryption, and the maximum length ecryptfs supports is
143 characters. Right, lemme try to get it to skip that test if the ln fails...

>> Do you mean the tests/truncate.test entry:
>>
>> testing "is sparse" "truncate -s 1g freep && [ $(stat -c %b freep) -le 8 ] &&
>> echo okay" "okay\n" "" ""
>>
>> Which is doing a "truncate -s 1g file" and then asking state if the file with
>> literally no contents used less than 8 512-byte blocks of storage?
> 
> That's the one

Try now.

>> Is it triggering ASAN in mkpasswd or in a different toybox command out of the
>> $PATH? (Yay reproduction sequence, but WHAT did it reproduce?)
> 
> Putting toybox commands into my PATH runs test_mkpasswd fine, So I don't think it's some other toybox command.
> And since the lib/password.c plumbing got rewritten and needs to be audited that naturally seemed
> like the issue.

Quite likely. I wonder why it's passing for me?

Rob