[Bug 256233] security/doas: target user's login class gets ignored
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 256233] security/doas: target user's login class gets ignored"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 06 Jun 2021 18:36:35 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256233 --- Comment #26 from bugs.freebsd@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.