fix(cache): use process.geteuid() for virtual users

[ST-DDT]

Fixes #352

• Error uv_os_get_passwd returned ENOENT when updating to v3.14.0 #352
• fix(cache): scope cache directory to user #332

[privatenumber]

I realized this might not exist on Windows.

I'm currently refactoring the tests to be lighter so I can bring back Windows. Will hold this until then.

[privatenumber]

Windows doesn't seem to support geteuid() (no user ID?) so I'm considering using node-cachedir to store cache based in the user's home directory.

[dcousens]

What about os.userInfo().username as a fallback only on Windows?

Throws a SystemError if a user has no username or homedir.
(from https://nodejs.org/api/os.html#osuserinfooptions)

I don't know when that might happen, but you could default to a random tmpdir if it did

[privatenumber]

What's wrong with using node-cachedir?

[dcousens]

https://github.com/LinusU/node-cachedir/blob/1d8619a927cfc6cafb4543ed3ce46bc6558be99f/index.js#L5

> sudo -u nobody node -e "console.log(path.join(os.homedir(), '.cache'))"
/.cache

Unfortunately, that isn't going to help for your "virtual user" environments (or any user where a homedir is /).

[dcousens]

I think 2051f3e as written by @ST-DDT did a pretty good job, is cache sharing a problem on Windows?

[ST-DDT]

How about using "tsx-" + Math.random().toString().substring(2) => tsx-9675700890192862?

Works on all platforms and collisions are very unlikely. Or is there an implicit need to reuse the folder for the same user?

[dcousens]

Or is there an implicit need to reuse the folder for the same user?

Yes, your proposal is equivalent to tsx --no-cache, my understanding is the cache is shared between runs

[privatenumber]

On Linux, each user needs its own cache directory so it has the correct permissions to write to it. I'm not sure if this is a problem on Windows, but I rather keep the behavior consistent and also because the organization makes sense.

Do yall know if there's a way for me to test in the Linux virtual user environment? Hard to address it when I can't test the changes.

How about using "tsx-" + Math.random().toString().substring(2) => tsx-9675700890192862?

This defeats the point of the cache. (Module caching already happens inside Node). The cache is shared across multiple runs per user so it needs to be deterministic.

[ST-DDT]

I think on windows you always have a distinct username.

So Posix -> uid, Windows/Other -> username.replace(/\W+/g, '_')

[ST-DDT]

Do yall know if there's a way for me to test in the Linux virtual user environment? Hard to address it when I can't test the changes.

You could use a docker container for that.

[dcousens]

a way for me to test in the Linux virtual user environment

The bug reported returned an ENOENT error from uv_os_get_passwd, which may be because /etc/passwd had been omitted from the image.

You could reproduce that in a number of ways, but if you're not careful, you might break your test system.

[ST-DDT]

@privatenumber Did you close this PR by accident?

[privatenumber]

Oops, looks like it closed as a side-effect of auto-deletion happening on a merged PR.

The reopen button is disabled for me—I think because it's your PR. Would you mind re-opening it?

[ST-DDT]

I cannot because you closed it.
Maybe you have to change the target branch to an existing one before reopening is possible.
Otherwise I can open a new PR tomorrow.