Acabei de encontrar doas e, enquanto lia a página do manual para sua configuração , encontrei este exemplo :
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 é root, por que precisaria de permissões?
Nota: Eu marquei isso com sudo , pois doas é um substituto / sucessor, então talvez o raciocínio ou conceitos venham de sudo ou se apliquem a ambos.
Você tira esse comentário fora de contexto. Esta linha é útil quando constrói portas :
permit nopass keepenv root as root
As portas de construção sempre chamam doas . Sem a linha acima, isso restringiria as variáveis de ambiente mesmo ao criar portas como root . Com as portas de construção de linha, como root é feito com o ambiente completo.
Não concordo com parte da outra resposta: a criação de portas por iself enfaticamente não sempre chame sudo (ou doas) e deve ser feito por um usuário regular (dedicado). Apenas alguns dos alvos da marca, por ex. aqueles que instalarem ou desinstalarem portas, como make install , chamarão o programa SUDO , se ele tiver sido especificado em /etc/mk.conf ou no ambiente. O motivo para mencionar essa configuração no manual é para compilações em massa com dpb (1).
A razão pela qual a linha está lá é compatibilidade com o arquivo sudoers padrão do OpenBSD, como o enviar mensagem menciona:
CVSROOT: /cvs
Module name: src
Changes by: [email protected] 2015/08/28 07:19:50
Modified files:
usr.bin/doas : doas.conf.5
Log message:
Document an example that lets root run unrestricted doas commands as
root ("permit nopass keepenv root as root"), matching the old
behaviour from OpenBSD's sudoers file ("root ALL=(ALL) SETENV: ALL").
OK sthen@
Por que isso é útil? Imagine um script que faz algumas coisas que precisam de privilégios de root, algo assim:
#!/bin/sh
cmd1
doas cmd2
cmd3
Você pode executar esse script com êxito apenas como um usuário com permissão para usar o doas. Por padrão, o usuário no - nem mesmo o root - tem o direito de usar o doas; você precisa ativar explicitamente adicionando regras a /etc/doas.conf .
Sem a linha permit root as root , o script acima falharia se você o executasse como root, o que é provavelmente surpreendente e inconveniente.
Agora vem a parte em que eu concordo com a outra resposta: como mencionado acima, os scripts de construção padrão no OpenBSD têm a variável SUDO que você pode definir como sudo ou doas para elevar os privilégios. Se algum comando for executado sob $SUDO , você deseja preservar variáveis de ambiente, como prefixos de diretório e outras coisas necessárias para o sistema de compilação funcionar corretamente.
Mais uma coisa: observe que apenas o primeiro grande exemplo no excerto manual citado é destinado a construir portas. Leia o texto citado como uma lista com marcadores com quatro itens independentes:
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.
Obviamente, o exemplo envolvendo procmap não tem nada a ver com a construção de portas e o segundo exemplo é apenas o costumeiro que membros da roda de grupo são aqueles que podem elevar privilégios à raiz (por exemplo, su, sudo ou doas). / p>
Agora, por que você quer isso? Bem, alguns scripts ou makefiles contêm uma variável SUDO. Por padrão, nenhum usuário tem o direito de usar o doas. Você precisa incluir explicitamente adicionando regras a /etc/doas.conf .