On Fri, 29 Nov 2024 10:47:55 -0700
"Theo de Raadt" <deraadt@openbsd.org> wrote:

> Aaron Rainbolt <arainbolt@kfocus.org> wrote:
> 
> > At the very least, would the umask handling feature be welcome? The
> > only place umask modifications can be made reliably when working
> > with privilege escalation is in the privilege escalation utility
> > itself, due to the fact that it behaves almost like an environment
> > variable. The workaround is to use a wrapper script, but that is a
> > horrible hack that I would like to avoid if at all possible (though
> > again, my downstream will survive if we must). I can definitely see
> > this being useful in OpenBSD itself, separate from any other
> > project.  
> 
> I am not seeing the use case:
> 
> 1) noone will actually use it, or know when they need to use it
> 
>    The problem specification is too complex for regular humans to
>    understand.

The use case is simple - the system administrator wants to keep files
written by individual users from being read by all users, but also
wants configuration files written or edited by root to remain
world-readable.

> 2) Once you need to handle this, are there other problems??  yes,
> almost for sure you have other "process conditions" created in the
> unix pipe / fd inheritance / non-$ENV environment, and you SHOULD be
> using a wrapper around the complicated program you are running.

I don't really see how other non-$ENV environment is relevant here.
doas explicitly does things with umask already. This isn't adding any
other bits of environment to what doas handles, it only makes it so
that the administrator can secure their system better.

> Using a wrapper script is not a "horrible hack". A wrapper is the
> correct place to sanitize.  doas should not grow "a pile of features"
> as more non-$ENV environmental concerns with sub-commands are
> discovered.

Again, other non-$ENV environmental concerns are out of scope since
doas doesn't handle them. And sure, a wrapper script isn't the end
of the world, especially in an environment where you can divert an
executable to an alternate location and make the wrapper "take over"
the original spot. OpenBSD doesn't support that kind of diversion to my
awareness though, does it?