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

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 06 Jun 2021 18:36:35 +0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256233

--- Comment #26 from bugs.freebsd_at_scourger.nl ---
Ok, maybe it's considered intended behaviour and not a bug. But it would be
nice if this is mentioned in the manual page somehow, because the current
description of -S doesn't make this clear at all. I think many people would
expect it to be similar to "su -", when in fact it isn't. Right now I'm really
at a loss of what the -S is supposed to do, and in what ways it is intended to
be different from -s.

So I did a few more tests hoping to wrap my head around it. Until now, I've
mostly been testing without the keepenv setting. However, when keepenv is
defined in doas.conf, things get weird. Observe the difference in behaviour
without and with keepenv:

permit nopass alice as bob
  In this case, "doas -u bob -S" resets all environment variables, and you end
up with a very minimal environment.

permit nopass keepenv alice as bob
  With keepenv defined, "doas -u bob -S" actually results in a shell with all
environment variables set according to bob's (!!!) login class. This includes
the language! It also includes variables from the "setenv" line in login.conf.

With keepenv, doas -S is exactly doing what I always expected it do when
keepenv is NOT set! What's happening here?


Regarding original design and consistency between platforms, I'd like to
mention that upstream (doas on OpenBSD) doesn't even have the -S flag at all.
Maybe there's a good reason they never included it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
Received on Sun Jun 06 2021 - 18:36:35 UTC

Original text of this message