On Fri, Dec 17, 2021 at 09:20:59PM -0800, David Newman wrote:
> Thanks for this. I get similar results where doas shows root's PATH -- but I
> cannot execute a file called '/usr/local/sbin/s', which is owned by
> root:root and has 0750 permissions, unless I specify the full path:
>
> dnewman@coppi:~$ echo $PATH
> /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> dnewman@coppi:~$ cat /etc/doas.conf
> permit nopass setenv {
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } dnewman
> dnewman@coppi:~$ doas env | grep PATH
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> dnewman@coppi:~$ doas s mailman3
> doas: s: command not found
> dnewman@coppi:~$ doas /usr/local/sbin/s mailman3
> ● mailman3.service - GNU Mailing List Manager
> ..
Same here, and it's not the permissions that are the issue.
unicorn:~$ PATH=/usr/local/bin:/usr/bin:/bin
unicorn:~$ type fdisk
bash: type: fdisk: not found
unicorn:~$ doas fdisk -l | head -n2
doas (greg@unicorn) password:
doas: fdisk: command not found
unicorn:~$ doas /sbin/fdisk -l | head -n2
doas (greg@unicorn) password:
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: TOSHIBA DT01ACA1
Looks like doas performs the search for the command *before* it sets
the environment. You'd need to petition the developers to make a change
to the program's behavior in order to get what you want. Most likely
this would need to be argued upstream, as I cannot imagine Debian writing
a local patch for that. Not in a setuid program like this, and not after
the bullshit they pulled with su in buster.
