DEFAULT_USER_UID and DEFAULT_USER_GID are implemented incorrectly, erroring out in Docker

[micolous]

Atomically attempts to get the current UID and GID using multiple calls to os.userInfo() at import time:

https://github.com/fabiospampinato/atomically/blob/6918c035a288094dc8d4339a2b28bdea20293dcb/src/constants.ts#L19-L21

os.userInfo() calls uv_os_get_passwd(), which on UNIX-like systems calls uv__getpwuid_r(..., geteuid()), and looks up information with getpwuid_r.

There are a few issues with the approach:

• DEFAULT_USER_GID is the effective UID's default group according to the password file (or storage system), rather than the process' effective GID (getegid())
• There are two identical calls to getpwuid_r(), which can be slow if the system has a large passwd file, or uses a network directory service (NIS, LDAP, etc.)
• If running an application in a container system like Docker:
  • the effective UID of a process may not even have an entry in /etc/passwd, which causes an error like A system error occurred: uv_os_get_passwd returned ENOENT (no such file or directory) at import time, with no way for the error to be handled
  • the entry in /etc/passwd may exist, but be completely wrong, causing the effective GID to be incorrect

Expected behaviour

This should use process.getegid() and process.geteuid() on UNIX-like systems.

These do not depend on getpwuid_r.

Calling these functions probably doesn't make sense on Windows.

[Roman2dot0]

This issue affects some projects. For example, drawio-desktop installed by snap and used by ldap user (so without user info in /etc/passwd).

https://github.com/jgraph/drawio-desktop/issues/1861

[nim65s]

also ref. https://github.com/element-hq/element-desktop/issues/2046

[vorburger]

This also affects the Google Gemini CLI.

#16 is a PR with a proposed fix for this.

[fabiospampinato]

I've merged #16 and shipped the fix in v2.0.5. Thanks for the deep dive 👍