Não é possível do jeito que você quer, onde se um usuário executa o arquivo, ele é executado setuid, mas se outro usuário executa o arquivo, ele é executado sem setuid. O bit setuid não está incluído nas listas de controle de acesso. Está ativado ou não para um arquivo.
Você pode obter parcialmente para o seu objetivo. Você pode permitir que apenas determinados usuários executem um arquivo setuid, mas outros usuários serão proibidos de executá-lo.
Por exemplo, considere o programa "privileged_command" fictício. Se você quiser torná-lo setuid, mas permitir que apenas membros do grupo adm o executem por meio de um acl, você poderá fazer isso por:
$ chown root.root privileged_command
$ chmod 4000 privileged_command
$ ls -l privileged_command
---S------ 1 root root 152104 Nov 17 21:15 privileged_command
$ setfacl -m g:adm:rx privileged_command
Este é um exemplo muito simples e muito factível com apenas permissões de grupo. Mas você pode continuar usando o setfacl para criar um conjunto complexo de usuários / grupos que podem e não podem executar o programa. O único problema é que todos que são capazes de executar o comando irão executá-lo. Qualquer outra pessoa só terá permissão negada e não poderá executá-la.
Isso é o mais perto que posso pensar de chegar ao que você está realmente perguntando. Dito isto, o que você está pedindo provavelmente é uma Idéia Ruim ™. As práticas recomendadas para privilégios extras são para os usuários que estão autorizados a exercerem esses privilégios a serem obrigados a ativamente assumir essa autoridade quando e somente quando pretenderem agir com essa autoridade. Esse é todo o propósito por trás do sudo. Fazer com que determinados comandos automaticamente atuem com privilégios diferentes, dependendo de quem os está executando, é uma receita para uso indevido acidental. Essa é a razão pela qual você normalmente não faz login como root o tempo todo.
Além disso, o uso de ACLs dessa forma é uma receita para falhas de segurança posteriores. As ACLs raramente são usadas e, ainda mais raramente, são necessárias. Neste caso, usando-os para controlar quem pode executar um programa setuid, não é imediatamente óbvio quem tem quais privilégios, não há arquivo central ou repositório mostrando quem tem qual autoridade ou quais condições de ACL estão em quais arquivos. Pode rapidamente tornar-se um pesadelo administrativo.
Eu não direi que nunca há um lugar para usar uma ACL, mas eu posso contar em uma mão com muitos dedos não usados, o número de vezes que eu vi um caso convincente que é uma boa idéia. / p>