[pferde]

The proper fix would be to not use getent CLI tool in their logic, but instead use proper system APIs for looking up user account entries, like one of earlier comments here already mentions. This is shocking amateur hour!

My guess is they hastily threw together something hacky in early development, and forgot to replace it with a real, safe solution later.

[rfoo]

The issue here is there is NO single system API for looking up user account entries on Linux.

It's implemented in libc. So you need to link to libc. Tailscale is a Go binary, and they probably prefer it to be statically-linked. glibc NSS implementation also REQUIRES you to load `.so` so you just can't emulate it in Go.

Then, "link to libc". Which libc? glibc? musl?

[pferde]

But of course there is, it's part of POSIX, implemented in libc. And if you're using a higher level language, they all have their own wrappers around libc/POSIX APIs. Here is golang's: https://pkg.go.dev/os/user

[dchest]

Which uses libc via CGO or parses /etc/passwd with no CGO, which won't work for some cases.

https://github.com/tailscale/tailscale/blob/e4144230f410204a...

  // userLookupGetent uses "getent" to look up users so that even with static
  // tailscaled binaries without cgo (as we distribute), we can still look up
  // PAM/NSS users which the standard library's os/user without cgo won't get
  // (because of no libc hooks). If "getent" fails, userLookupGetent falls back
  // to the standard library.

[eviks]

Thanks, that's what I didn't get from the other discussion, so it seems to be a rather trivial fix - just use the existing language functionality

[Chu4eeno]

> The issue here is there is NO single system API for looking up user account entries on Linux.

Yes there is, and you answered in the next line, it is implemented in libc.

If you want to check authentication use libc don't try to implement crypto and authentication yourself.

[catlifeonmars]

Others have pointed out that os/user.Lookup is a platform-independent way to resolve this, but additionally you don’t _need_ to link against glibc to use it.

If you are writing go, you usually want to set CGO_ENABLED=0 by default, to avoid inadvertently introducing nonportable code. In this way, only the pure Go implementations are used and there is no need to link (statically or dynamically) against a libc implementation to compile and run your programs.

[dchest]

With CGO disabled, it only reads /etc/passwd, while the glibc getpwnam(3) can query LDAP etc.

[catlifeonmars]

That’s not the use case of the tailscale daemon though, which was using getent passwd.

To clarify: I’m not against CGO, just introducing a glibc dependency by default. I would only introduce it when I needed it.