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.

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?

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

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.

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

> 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.

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.

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

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.

There is a whole class of security issues where fixes are worse that the issues themselves. Case in point, the OpenSSH itself that sends 100 packets on each keystroke to avoid timing attacks.

Why is that worse than the issue itself? If someone could figure out, say, my root password via an ssh timing attack, that seems bad. Sending 100 packets for each keystroke to protect against this seems cheap in the face of that.

Because it breaks our mental model of how things work.

Or it means it is time to update the model. Models need to change as the world they model changes, right?

The OpenBSD developers could have opted for a warning, like the one you see about post-quantum encryption when connecting to old servers.

Instead, they just sneaked the change upon the world.

The example doesn't seem worse, but more importantly - are these issues part of the class (and why)?