runtime: TestSUID hangs with "Password" prompt on FreeBSD

[prattmic]

@siebenmann reports that all.bash hangs with a "Password:" prompt on their FreeBSD machine due to runtime.TestSUID's su call.

Our FreeBSD builders allow su with no password (I think because our user is in the wheel group?). Presumably real FreeBSD systems don't put the main user in wheel. Or maybe su is asking for the password of the primary user? I'm not sure how this configuration works.

On my Linux workstation, the test skips as su seems to automatically exit with error (detects a non-interactive stdin perhaps?). Perhaps FreeBSD's su doesn't do this?

cc @golang/freebsd @rolandshoemaker

[gabyhelp]

Related Issues

• runtime: TestSUID prompts for password #60690 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[siebenmann]

It appears that the hang is in another test that is run as part of all.bash. Running the runtime tests alone with '../bin/go test runtime' (from the src/ directory of a current git tip) doesn't hang (but has other failures). During all.bash, the hang comes from net's TestDialParallelSpuriousConnection test. However, running the runtime tests alone shows two failures: first, that the Password: prompt is printed in things, and second that running su here mangles my tty attributes when I'm running all.bash from an interactive shell (turning off echo and other things). I am in group wheel but I don't have passwordless su enabled on this machine. It's my personal opinion as a sysadmin that tests should not blindly run su even if it produces no output and doesn't mangle the tty settings, because security systems may well react to failed su's to root or improper su's (su being run by people who aren't supposed to use it).

[ianlancetaylor]

FreeBSD has a doas command like OpenBSD. @siebenmann Does it work to change privesc in runtime/security_test.go to run doas on runtime.GOOS == "freebsd" as it already does for runtime.GOOS == "openbsd" ? In particular that passes the -n option which disables password checking.

I agree that ideally a test should not invoke su. But this particular test is exactly about testing a privileged operation. We could consider skipping the test if -test.short was used, except on the builders. That would not eliminate problems but at least it wouldn't show up for ordinary users using make.bash or run.bash.

[siebenmann]

The FreeBSD `doas` is only available as an optional pkg package and isn't part of the base system, so I don't think you can count on it being present. Installing the doas package and patching runtime/security_test.go to use it does avoid this su failure.

[ianlancetaylor]

Thanks. I filed #70708 to ask for doas to be installed on builders. When that happens we can change the test to use it, and avoid this problem.

[gopherbot]

Change https://go.dev/cl/634156 mentions this issue: runtime: in TestSUID use doas on FreeBSD

[bsiegert]

The doas package is now installed on the NetBSD LUCI builders (arm and arm64).

However, without a config file, all it prints is

doas: doas is not enabled, /usr/pkg/etc/doas.conf: No such file or directory

I am hesitant to give the swarming user the right to run all commands as root.

In addition, the LUCI infrastructure already uses sudo, so sudo is also installed and configured on these systems. The only allowed command for the swarming user is reboot, which it does after failed test runs. So my preference would be to add NetBSD to the darwin branch, which uses sudo. What do you think?

[prattmic]

We could potentially try both doas and sudo, but of course it is possible that neither works.

This seems like a test that we want an assertion that it isn't skipped on some builder we know is properly configured.