I want to be able to shutdown (or restart) my system without having to enter my password. My /etc/doas.conf looks like this and my user is in the wheel group permit nopass :wheel as root cmd /sbin/poweroff permit nopass :wheel as root cmd /sbin/reboot permit :wheel I thought this would be enough so I can enter $ poweroff but I get the message > poweroff: must be superuser. when I do $ doas poweroff I still have to enter my password. How can I configure doas so that my user can poweroff or reboot without having to enter my password? And is it possible to configure it so that I don't have to enter doas at all?

My host is on alpine Linux and I'm running a jenkins agent on docker. I need the jenkins agent to be able to run a script when it does a build that changes the ownership of a few directories. Every time I run the script as the jenkins user from the container I get "Operation not permitted". I'm able to run the script fine from the host and fine as root on the container. my dodas config (on host) is: permit persist :wheel permit nopass Local_Admin cmd /srv/scripts/setperm.sh permit nopass :wheel cmd /srv/scripts/setperm.sh I get this when I do id for my host account: uid=1000(Local_Admin) gid=1000(Local_Admin) groups=0(root),10(wheel),18(audio),27(video),28(netdev),1000(Local_Admin),1000(Local_Admin) on the container as the jenkins user i get uid=1000(jenkins) gid=1000(jenkins) groups=10(wheel),1000(jenkins) Any ideas? ***EDIT*** I don't know if it matters but here is the script and permissions #!/bin/sh chgrp -R jenkins /home/jenkins/docker-volumes chmod g+rwx -R /home/jenkins/docker-volumes echo "$USER" id and permissions dockingbay2:~$ cd /srv/scripts dockingbay2:/srv/scripts$ ls -l total 4 -rwsr-xr-x 1 root root 199 May 14 08:29 setperm.sh dockingbay2:/srv/scripts$

I have installed a Nix package on my ubuntu os, that depends on doas, and for it to function, it's binary need's to have the suid bit set - and it isn't in the default nix-env installation. On NixOS you can enable a suid wrapper for doas (nixos wiki ), but that has to be put into /etc/nixos/configuration.nix, which doesn't exist out of NixOS. Does anyone know how to set that configuration value or get doas to function in a different way

Is there a common way I can show a banner when a user sudo -s or doas -s on a host? I don't mean ssh/login banner, but starting a root shell via those methods.

doas is a sudo-like command recently packaged in Debian 12, Ubuntu Jammy (universe) and some other Linux distros. A non sudoers user (doasuser) can be added to /etc/doas.conf to be granted root access. Detailed instructions on Debian Wiki . Problem: The doasuser isn't a member of any group. If you grant root access to doasuser, this information isn't synchronized with sudo (seen as unprivileged user). doas only comes with a binary program, a PAM configuration file and /etc/doas.conf. Apart from /etc/doas.conf, a superuser can't find the permissions of the doasuser. Is there any command line to check the permissions of doasuser?

I wrote a simple playbook, open-links.yml, that is meant to run a script on one of my remote hosts:

- name: Run Bash script
  hosts: myhosts
  gather_facts: false
  vars:
    au: "j"
  tasks:
    - name: Copy and run a script that opens a link
      script: /home/{{ au }}/CS/SoftwareDevelopment/MySoftware/Bash/ansible/open-links.sh

open-links.sh is a script that is meant to open a link in a browser:

#!/usr/bin/bash


# Link to open
link_to_open="https://calendar.google.com/calendar/u/0/r "


doas -u oumaima echo "From ${0}, $(whoami): It works, doesn't it"|tee ~/debug.log
doas -u oumaima brave-browser "${link_to_open}" > /dev/null 2>&1 &
#doas -u oumaima DISPLAY=:0 brave-browser "${link_to_open}" > /dev/null 2>&1 &
#doas -u oumaima DISPLAY=:0.0 brave-browser ${link_to_open} > /dev/null 2>&1 &
#neither of these two work, whatever the value of DISPLAY

Although running ansible-playbook -u root -i inventory.ini open-links.yml gives me the following output

PLAY [Run Bash script] **********************************************************************************

TASK [Copy and run a script that opens a link] ***********************************************************
changed: [fe80::cc08:9465:8dba:15a9%wlp4s0]

PLAY RECAP **********************************************************************************************
fe80::cc08:9465:8dba:15a9%wlp4s0 : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

No link gets opened. The location of debug.log is /root/, and its content, ` From /root/.ansible/tmp/ansible-tmp-1702325377.165474-2513875-125933755232488/open-links.sh, root: It works, doesn't it `, both of them suggest to me that if any link does get opened, then it probably happens for root. When I am logged in with ssh to the remote host and manually run

link_to_open="https://calendar.google.com/calendar/u/0/r "
doas -u oumaima brave-browser "${link_to_open}" > /dev/null 2>&1 &

then the browser does open the link as specified for the user oumaima. I know that the link is open because the remote host is in the same room and I can seen the browser from the user account oumaima. **Forwarding to my control station of what is happening in the GUI of oumaima is not what I want and let it be outside of the scope of this question.** I just want the link to be opened. Why doesn't this happen when the script is run with ansible-playbook -u root -i inventory.ini open-links.yml I know that I could just work around that by allowing non-root logins to the remote host and running the playbook as oumaima, like so: ansible-playbook -u oumaima -i inventory.ini open-links.yml. Let such solutions be outside of the scope of this question. I'd like to fix the issue when running the playbook as root. **About the hosts**: a laptop in the same room, on the same LAN, as my control station. Ubuntu Desktop 22.04 LTS on both the control station and the remote host.

I want to run a command in the background as root. And I have a problem with **doas** command. With **sudo**, I can use sudo --background . It will ask for password, then runs in the background. I cannot do doas & because it will ask for the password in the background and stuck there forever. I've checked the manpage but did not find the equivalent option for **doas**.

This script works when executed with doas ./backup_cron_root.sh

#!/usr/bin/bash

/usr/bin/crontab -l> "/tmp/cron.$(whoami).$(hostname)" && /bin/date>>"/tmp/cron.$(whoami).$(hostname)" &&
/usr/bin/doas -u joanna /usr/bin/cp -f "/tmp/cron.$(whoami).$(hostname)" "/home/joanna/pCloudDrive/backups" &&
/usr/bin/rm "/tmp/cron.$(whoami).$(hostname)"

where ./backup_cron_root.sh is the name of the script. When the same script is scheduled as a cronjob with doas crontab -e and * * * * * /home/joanna/backup_cron_root.sh >/tmp/cronjob.log 2>&1 it creates /tmp/cron.root.joanna-ONE-AMD-M4 which is owned by root but for some reason it does not succeed in copying it to /home/joanna/pCloudDrive/backups. Why so? Why doesn't this script succeed from crontab as it does when manually run? The content of my /etc/doas.conf is

permit joanna as root
permit root as joanna

The following is my tail of grep CRON /var/log/syslog:

Feb 26 17:17:01 joanna-ONE-AMD-M4 CRON: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Feb 26 17:17:01 joanna-ONE-AMD-M4 CRON: (root) CMD (/home/joanna/backup_cron_root.sh)
Feb 26 17:17:01 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)
Feb 26 17:17:01 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)
Feb 26 17:17:01 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)
Feb 26 17:17:01 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)
Feb 26 17:17:22 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)
Feb 26 17:18:01 joanna-ONE-AMD-M4 CRON: (root) CMD (/home/joanna/backup_cron_root.sh)
Feb 26 17:18:01 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)
Feb 26 17:18:01 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)
Feb 26 17:18:01 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)
Feb 26 17:18:01 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)
Feb 26 17:18:22 joanna-ONE-AMD-M4 CRON: (CRON) info (No MTA installed, discarding output)

The content of /tmp/cronjob.log is

doas: Authentication failed

This is a question I've pondered for a long time and thought was impossible. Is it possible to prevent administrators of a machine from bypassing the audit capabilities of sudo or doas? For instance, running sudo su - and having a root shell? I suppose the real question is, is there a way to audit root's activity on a machine?

I've just come across doas, and while reading the [man page for its configuration](http://man.openbsd.org/doas.conf) I found this example: > The following example permits users in group wsrc to build ports; wheel to execute commands as any user while keeping the environment variables PS1 and SSH_AUTH_SOCK and unsetting ENV; permits tedu to run procmap as root without a password; **and additionally permits root to run unrestricted commands as itself**. # Non-exhaustive list of variables needed to # build release(8) and ports(7) permit nopass setenv { \ FTPMODE PKG_CACHE PKG_PATH SM_PATH SSH_AUTH_SOCK \ DESTDIR DISTDIR FETCH_CMD FLAVOR GROUP MAKE MAKECONF \ MULTI_PACKAGES NOMAN OKAY_FILES OWNER PKG_DBDIR \ PKG_DESTDIR PKG_TMPDIR PORTSDIR RELEASEDIR SHARED_ONLY \ SUBPACKAGE WRKOBJDIR SUDO_PORT_V1 } :wsrc permit setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } :wheel permit nopass tedu as root cmd /usr/sbin/procmap permit nopass keepenv root as root root is root, why would it need permissions? Note: I've tagged this with sudo as doas is a substitute/successor, so perhaps the reasoning or concepts will come from sudo or apply to both.

From my limited understanding, the doas utility allows you to run any command as root but, by default, requires you to enter your own password instead of the root user's password. How do I make it require root password instead?

I'm using Debian/GNU/Linux Unstable, and I was trying doas for the first time today, with the following simple config file:

$ doas cat /etc/doas.conf 
permit persist alx as root

While it worked for some time (I could for example run doas apt-get update && doas apt-get upgrade), the following failed:

alx@ady1:~$ doas gdisk /dev/sdb
doas: gdisk: command not found

Hmm, is it that gdisk is an sbin binary? apt-get is a bin binary. Maybe the PATH is wrong. Let's check it:

$ sudo env | grep PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ doas env | grep PATH
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

doas seems to know sbin, but there seems to be something reversed in the PATH. Okay, where's gdisk?

alx@ady1:~$ sudo which gdisk
/usr/bin/which: this version of which' is deprecated; use command -v' in scripts instead.
/usr/sbin/gdisk
alx@ady1:~$ doas which gdisk
/usr/bin/which: this version of which' is deprecated; use command -v' in scripts instead.
/sbin/gdisk

command -v wouldn't work here, as it's a builtin, and won't work with sudo or doas, but let's ignore that warning (why would which be deprecated if there's no proper replacement?). Hmm, they don't agree. Let's see:

$ realpath /usr/sbin/gdisk 
/usr/sbin/gdisk
$ realpath /sbin/gdisk
/usr/sbin/gdisk
$ ls -l /sbin 
lrwxrwxrwx 1 root root 8 Nov 11 15:37 /sbin -> usr/sbin

Maybe it's due to the symlink that doas has trouble believing it should execute this binary? Let's modify the PATH so that it first finds the real path:

$ doas PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin gdisk /dev/sdb
doas: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin: command not found

Huh, this is weird. Let's try using normal syntax (as opposed to sudo syntax; isn't this inconsistent or is it just me?):

$ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin doas gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): q
$

Okay, now it finds it. What should be the correct fix for this problem? Am I missing anything in the configuration?

How may I change my doas prompt? For example, to change sudo prompt you just run

export SUDO_PROMPT="Prompt: "

Is there an equivalent for doas?

There are two normal users on my OpenBSD machine ("user" and "TESTUSER") and I have this doas config: # cat /etc/doas.conf permit setenv { DISPLAY=:0 } nopass user /usr/X11R6/bin/xcalc as TESTUSER # But when I try to run the "xcalc" with the "user" (as "TESTUSER") I only got a syntax error: $ id uid=1000(user) gid=1000(user) groups=1000(user), 0(wheel) $ doas /usr/X11R6/bin/xcalc doas: syntax error at line 1 $ **The Question**: what syntax error did I make? https://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/doas.1 https://man.openbsd.org/doas.conf

On OpenBSD 7.2 stable, I've setup my chroot using this script:

#!/bin/ksh

dir="/jails/$1"
mkdir -p "$dir"

tar -C "$dir" -xzf /usr/src/base/base72.tgz
tar -C "$dir" -xzf /usr/src/base/comp72.tgz
tar -C "$dir" -xzf /usr/src/base/man72.tgz
tar -C "$dir" -xzf /usr/src/base/xbase72.tgz
tar -C "$dir" -xzf /usr/src/base/xfont72.tgz
tar -C "$dir" -xzf /usr/src/base/xserv72.tgz
tar -C "$dir" -xzf /usr/src/base/xshare72.tgz

(cd "$dir/dev" && doas ./MAKEDEV all)

doas cp /etc/{doas.conf,installurl,resolv.conf,master.passwd,passwd,group} "$dir/etc/"
mkdir -p "$dir/home/evan"
chown evan:wheel "$dir/home/evan"

doas chroot "$dir" pwd_mkdb /etc/master.passwd
doas chroot "$dir" ldconfig /usr/local/lib
doas chroot "$dir" sysmerge

While logged-in as the user evan, I enter my chroot using doas chroot /jails/project /usr/bin/su - evan I try running doas pkg_add cowsay and I get this error:

doas: not installed setuid

What am I missing?

sudo wget -qO- https://go.dev/dl/go1.20.1.linux-amd64.tar.gz|sudo tar -xz works fine. doas wget -qO- https://go.dev/dl/go1.20.1.linux-amd64.tar.gz|doas tar -xz does not work. I get no input, it just freezes on me. I'm able to run other, simpler, commands with doas. I'm on Ubuntu 22.04 LTS (I installed doas with apt install doas) and my /etc/doas.conf is permit jim as root. Why doesn't the command with doas work as with sudo? Do I need to further configure doas for the command to work?

I want to configure doas so that it asks for root password, but not for normal user password. How do I do that?