Em sistemas que o suportam (GNU e muitos outros), você poderia fazer:
sudo find /path/ -print0 | xargs -r0 process_paths
xargs
não é executado sob sudo
, portanto ainda tem os uids / gids originais e também o ambiente original (no sentido mais amplo), não o modificado por sudo
.
process_paths
stdin acaba sendo modificado (dependendo da implementação do xargs
, ele está aberto no /dev/null
ou compartilha o pipe
do sudo
/ find
.
Para evitar isso (com o GNU xargs
e shells como ksh
, zsh
ou bash
que suportam a substituição do processo), você poderia fazer:
xargs -r0a <(find /path/ -print0) process_paths
com zsh
:
sudo zsh -c '
files=(/path/**/*(D))
USERNAME=$SUDO_USER
autoload zargs
zargs $files -- process_paths'
Em zsh
, atribuir um nome de usuário à variável $USERNAME
special configura os uids, gids para o usuário correspondente no banco de dados do usuário, como sudo -u "$SUDO_USER"
faria.
Você poderia fazer:
sudo sh -c '
exec find /path/ -exec sudo -u "$SUDO_USER" process_paths {} +'
Mas como sudo
passa uma variável de ambiente $SUDO_COMMAND
(que contém a concatenação dos argumentos com espaços) para process_paths
, a lista de arquivos acaba sendo passada duas vezes para process_paths
, o que significa o limite no O tamanho máximo de args + env provavelmente será alcançado se houver um grande número de arquivos.
Com a maioria das implementações su
, você deve ser capaz de fazer:
sudo sh -c '
exec find /path/ -exec su "$SUDO_USER" -c '\''
exec "$0" "$@"'\'' process_paths {} +'
embora como su
não tenha o mesmo problema.