[BUG] extract with strip can change permissions on existing files when running as root

What / Why

When the tar utility runs with --strip-components and -p (or as root), no existing directories have their permissions changed. However, when node-tar does the equivalent, the existing filesystem can be mutated.

How

Steps to Reproduce

In an empty directory, run

mkdir dir
sudo chown 501 dir
tar -czf tarball.tgz dir
sudo node - <<JS
const tar = require('tar')
tar.x({file: 'tarball.tgz',strip:1})
JS
ls -an

Expected Behavior

When I run

mkdir dir
sudo chown 501 dir
tar -czf tarball.tgz dir
sudo tar --strip-components=1 -xzf tarball.tgz
ls -an

which should be roughly equivalent, the output is

total 8
drwxr-xr-x   4 502  20   128 17 Sep 18:08 .
drwxr-xr-x  46 502  20  1472 17 Sep 18:08 ..
drwxr-xr-x   2 501  20    64 17 Sep 18:08 dir
-rw-r--r--   1 502  20   110 17 Sep 18:08 tarball.tgz

Actual Behavior

When I run the above script using node-tar, the output is

total 8
drwxr-xr-x   4 501  20   128 17 Sep 18:09 .
drwxr-xr-x  46 502  20  1472 17 Sep 18:09 ..
drwxr-xr-x   2 501  20    64 17 Sep 18:09 dir
-rw-r--r--   1 502  20   110 17 Sep 18:09 tarball.tgz

The results are almost identical, except in the node-tar case the current directory has changed ownership from UID 502 to UID 501.

References

I encountered this while investigating a problem with running backstage's tests.

Start by reproducing the documented node-tar extraction with --strip-components while running as root, then inspect the extraction path that handles existing directories and ownership. Done means the current directory remains owned by UID 502, matching the system tar behavior, with coverage for the reported command.