Re: doas 101 question
On Fri, Dec 24, 2021 at 08:32:14PM -0800, David Robert Newman wrote: > I asked doas author Ted Unangst about this. His reply: > > > Sorry, only very limited env replacement can be done in setenv. root's > > environment isn't available before the switch. > > Ergo, it is just as you suspected. This isn't an issue with OpenBSD because > regular users's PATHs already include sbin directories. It is an issue with > Debian because (a) a regular user's PATH doesn't include sbin directories > and (b) the change in su behavior awhile back restricted access to some root > privileges. It's not an issue with sudo, but for various reasons I'm more > comfortable using doas. > > My workaround was to add aliases for a few commands to my .bashrc file, e.g. > (but not a real example): > > alias ua='doas /usr/sbin/useradd' In order to use doas, you already have to customize your system (it does nothing out-of-the-box). You might as well take another step, and customize your login so that your PATH contains /usr/local/sbin and so on. The details of how to do this are extremely specific to how you login, but it should be pretty simple if you know what you're doing.
Re: doas 101 question
On 12/18/21 7:08 AM, Greg Wooledge wrote:
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.
I asked doas author Ted Unangst about this. His reply:
Sorry, only very limited env replacement can be done in setenv. root's
environment isn't available before the switch.
Ergo, it is just as you suspected. This isn't an issue with OpenBSD
because regular users's PATHs already include sbin directories. It is an
issue with Debian because (a) a regular user's PATH doesn't include sbin
directories and (b) the change in su behavior awhile back restricted
access to some root privileges. It's not an issue with sudo, but for
various reasons I'm more comfortable using doas.
My workaround was to add aliases for a few commands to my .bashrc file,
e.g. (but not a real example):
alias ua='doas /usr/sbin/useradd'
Thanks for the sanity check.
dn
Re: doas 101 question
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.
Re: doas 101 question
On Fri, 17 Dec 2021, 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
..
Do you have an alias for s?
tim@einstein(4):~$ l
/home/tim/bin/l says hello world
tim@einstein(4):~$ alias l='PATH=/bin l'
tim@einstein(4):~$ l
bash: l: command not found
tim@einstein(4):~$ /home/tim/bin/l
/home/tim/bin/l says hello world
The other thing I can think of is you need to run hash -r
(I don't know what doas is, I'm just making guesses)
Re: doas 101 question
On 12/17/21 8:16 PM, Greg Wooledge wrote:
On Fri, Dec 17, 2021 at 12:20:43PM -0800, David Newman wrote:
How to configure /etc/doas.conf so a non-root user gets root's PATH?
This works for me:
unicorn:~$ PATH=/usr/local/bin:/usr/bin:/bin
unicorn:~$ cat /etc/doas.conf
permit setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } greg
unicorn:~$ doas env | grep PATH
doas (greg@unicorn) password:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
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
..
permit nopass setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } dnewman
as root
permit nopass keepenv root as root
permit nopass setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } dnewman as root
permit nopass keepenv root as root
You've got two contradictory lines for "dnewman as root", with the latter
having a setenv clause without PATH in it.
Clarification: The examples in my previous email were two different
two-line configurations. It wasn't a four-line doas.conf file.
The second two-line example was taken from an OpenBSD box where invoking
doas allows execution without the full path. However, in that case I
think it's because regular users already have /usr/local/sbin in their
PATH, and so possibly unrelated to doas.
I would imagine the latter
wins out (because it occurs last), and therefore your PATH variable doesn't
get set.
I don't know how repeated "dnewman as root" lines would be handled if only
one of them had a setenv clause. You could experiment and find out. It
would be easier just to get rid of the second line.
Good idea. Per the example above it's just one line now, similar to yours.
dn
Re: doas 101 question
On Fri, Dec 17, 2021 at 12:20:43PM -0800, David Newman wrote:
> How to configure /etc/doas.conf so a non-root user gets root's PATH?
This works for me:
unicorn:~$ PATH=/usr/local/bin:/usr/bin:/bin
unicorn:~$ cat /etc/doas.conf
permit setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } greg
unicorn:~$ doas env | grep PATH
doas (greg@unicorn) password:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> permit nopass setenv {
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } dnewman
> as root
> permit nopass keepenv root as root
>
> permit nopass setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } dnewman as root
> permit nopass keepenv root as root
You've got two contradictory lines for "dnewman as root", with the latter
having a setenv clause without PATH in it. I would imagine the latter
wins out (because it occurs last), and therefore your PATH variable doesn't
get set.
I don't know how repeated "dnewman as root" lines would be handled if only
one of them had a setenv clause. You could experiment and find out. It
would be easier just to get rid of the second line.
doas 101 question
bullseye 11.1, 5.10.0-9-amd64, doas 6.8.1-2
How to configure /etc/doas.conf so a non-root user gets root's PATH?
Neither of these options work when attempting to execute a command in
/usr/sbin via doas (e.g., 'doas '):
permit nopass setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin }
dnewman as root
permit nopass keepenv root as root
permit nopass setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } dnewman as root
permit nopass keepenv root as root
The latter is from doas on OpenBSD, but I think that works because
non-root user accounts already have various sbins in their PATH.
I'm aware that linux-utils changed behavior a few years ago, and that
non-root users have a more restricted PATH. However, I'm unclear on what
steps to take so that non-root users can temporarily use root's PATH.
Thanks.
dn
