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.