Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #243224 > unrolled thread

doas 101 question

Back to article view | Back to linux.debian.user

Contents

  doas 101 question David Newman <dnewman@networktest.com> - 2021-12-17 21:40 +0100
    Re: doas 101 question Greg Wooledge <greg@wooledge.org> - 2021-12-18 05:20 +0100
      Re: doas 101 question David Newman <dnewman@networktest.com> - 2021-12-18 06:30 +0100
        Re: doas 101 question Tim Woodall <debianuser@woodall.me.uk> - 2021-12-18 08:00 +0100
        Re: doas 101 question Greg Wooledge <greg@wooledge.org> - 2021-12-18 16:10 +0100
          Re: doas 101 question David Robert Newman <david@davidrobertnewman.com> - 2021-12-25 06:00 +0100
            Re: doas 101 question Greg Wooledge <greg@wooledge.org> - 2021-12-25 15:00 +0100

#243224 — 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 <command name, without full path>'):

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

[toc] | [next] | [standalone]

#243225

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.

[toc] | [prev] | [next] | [standalone]

#243226

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


> 

[toc] | [prev] | [next] | [standalone]

#243227

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)

[toc] | [prev] | [next] | [standalone]

#243240

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.

[toc] | [prev] | [next] | [standalone]

#243433

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





>

[toc] | [prev] | [next] | [standalone]

#243439

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web