[Bug 256233] security/doas: target user's login class gets ignored

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256233

--- Comment #6 from bugs.freebsd@scourger.nl ---
Calling doas with the keepenv flag should indeed keep the language settings
from the caller intact. In the same vein, when a locale is explicitly provided
though the setenv flag, it should be used.

We also seem to agree that the caller doesn't want 'unexpected' language
changes.
But this is where it gets murky: if no language is passed to doas (by keepenv
or setenv), the language is going to change nonetheless. Without keepenv, I see
two possible outcomes:
1. The environment is cleared, and the command is executed using the "C"
locale. This happens in the current situation (*). I'm not sure if this is what
most people would expect.
2. The language from the target user's login class gets used. This is what
initially made more sense to me, because I wasn't expecting the C locale.

(*) Initially, I thought it used the language defined in the default login
class. In reality, it always seems to apply the C locale.


Now that I have given all this a bit more thought, this whole conundrum stems
from the fact that specifying lang in login.conf is just a way to set a regular
environment variable. Conversely, doas clears virtually all environment
variables by design. But some essential environment variables will allways be
set (regardless of keepenv and setenv), such as DOAS_USER, HOME, TERM, PATH and
SHELL.
Now the big question is: should LANG also be in that list (i.e. considered
essential)?

The way it is now, you'd have to explicitly specify "setenv { LANG }" to keep
the caller's language or use "setenv { LANG=en_US.UTF-8 }" to match bob's
language. When nothing is specified, you'll get the C locale.
Consider if the same thing happened with HOME or SHELL. My guess is that most
people would argue those shouldn't be reset to the system default, but instead
use the target user's shell.
Should or shouldn't LANG be handled in the same way as SHELL, TERM or HOME? I'm
not saying it should, but it would definitely make sense to me. 


Another thing I noticed is that the default PATH is hardcoded in doas (on
FreeBSD). I've checked how this is handled on OpenBSD, and there "doas -u bob
printenv" yields the PATH as defined for bob's login class in /etc/login.conf.
Do you know the reason why is's hardcoded on FreeBSD?

When I look at the behaviour of the original doas on OpenBSD, it appears that
the environment from the target login class is always applied (with the caveat
that OpenBSD lets you specify less options in login.conf compared to FreeBSD,
"lang" being one of the missing ones). My guess is that the original design of
doas was to respect environment variables defined in login classes, except
where it really doesn't make sense. Maybe is's a good idea to ask upstream
about this?

-- 
You are receiving this mail because:
You are the assignee for the bug.