I've made some changes to how doas handles environment variables recently. The diffs were in previous emails, and have been committed. Thanks to Sander Bos for pointing out some particular edge cases with the old handling.
There are two (or more) ways to run doas. In the first, you use it to run some commands as root. I use doas to run ifconfig to adjust the network on my laptop. I also know the root password, but doas is a bit quicker and easier. Either way, I'm fully trusted. Another way to use doas is to setup a restricted root setting for an untrusted user. This is treading on thin ice, in my opinion, since there may be ways for the untrusted user to escape. The unix security model isn't very good at letting somebody be root, but only kinda sorta. Which brings us to environment variables. doas (previously) allowed the new process to inherit HOME and PATH (among other variables) from the invoking user. This reflected my attitude that, yeah, I'm running this program as another user, but I'm still me. This however, causes trouble where if you try to set up a restricted root setting, an evil doer can specify their own PATH and possibly get a shell script to exec something. I think people knew this, but maybe didn't pull on the string to see how far it goes? So Sander looked into this, and discovered even a simple command like less is potentially unsafe to run as restricted root. less will execute commands if specified in the LESSOPEN environemnt variable, however even if that's not set, it will open $HOME/.less and allow setting it from there. If you study the manual sufficiently, it's all in there. (Setting LESSSECURE would have been the safe thing if you wanted to restrict a user to just less, but I think the general point remains that programs read all sorts of files, and everything needs to exec everything else.) After some reflection, I've been convinced that it's unlikely everybody reads the manuals, or that the manuals are even correct or complete. So the new doas behavior moving forward is to reset most everything to the target user's environment. Your action items, as we like to say in the biz, are: 1. Check existing configs for "restricted root" rules and verify that they are run with the correct environment. 2. When updating, check for rules that intentionally use inherited environment variables. They may need to be explicitly passing using setenv in doas.conf.
