Perder permissões adicionando capacidade?

O que está acontecendo aqui é que seu processo de "unshare" não tem acesso para gravar nos arquivos setgroups(e uid_maps, ) no namespace de usuário externo .gid_maps

Nesse namespace, os pseudo-arquivos /proc/<PID>serão de propriedade do root e, como se seu uid efetivo ainda fosse o de seu próprio usuário, você não terá acesso para gravar nesses arquivos.

Você pode visualizar isso facilmente executando um processo em segundo plano (como sleep) e inspecionando as permissões do setgroupsarquivo enquanto ele está em execução ( uid_mapse gid_mapsse comportando exatamente da mesma forma).

Primeiro, com um binário que não possui recursos adicionais:

$ cp /usr/bin/sleep .
$ ./sleep 10 &
[1] 11209
$ ls -l /proc/11209/setgroups
-rw-r--r--. 1 myuser myuser 0 Jul 31 12:33 /proc/11209/setgroups
[1]+  Done                    ./sleep 10
$

Em seguida, vamos adicionar alguns recursos de arquivo a ele e ver a mudança de propriedade:

$ sudo setcap cap_net_bind_service=ep sleep
$ ./sleep 10 &
[1] 11220
$ ls -l /proc/11220/setgroups 
-rw-r--r--. 1 root root 0 Jul 31 12:34 /proc/11220/setgroups
[1]+  Done                    ./sleep 10
$

A propriedade dos arquivos /proc/<PID>é controlada pelo sinalizador "dumpable" dentro do kernel do Linux, que é usado para evitar o vazamento de informações de um processo privilegiado para um usuário não privilegiado.

E considerando que você está executando com recursos adicionais, mas ainda com um uid efetivounshare não root , o acesso de gravação a esses pseudo-arquivos pertencentes ao root é impedido pelos controles de acesso normais do sistema operacional.

Você pode inspecionar o valor do sinalizador "dumpable" usando o PR_GET_DUMPABLEcomando da syscall prctl(2) .

Na descrição para PR_SET_DUMPABLEvocê também encontrará:

Normalmente, esse sinalizador é definido como 1. No entanto, ele é redefinido para o valor atual contido no arquivo /proc/sys/fs/suid_dumpable(que por padrão tem o valor 0), nas seguintes circunstâncias:

[...]

• O processo executa ( execve(2)) um programa que possui recursos de arquivo (consulte capabilities(7)), mas somente se os recursos permitidos obtidos excederem os já permitidos para o processo.

Que é exatamente o seu caso, com um unsharebinário que possui recursos de arquivo.

Curiosamente, usar um binário setuid de propriedade de root para unsharenão se depara com esse problema exato. Sim, ele limpará os sinalizadores "dumpable" e os arquivos /proc/<PID>serão de propriedade do root. Mas considerando que seu uid efetivo também é root ao executar um binário setuid, o acesso será permitido.

Nesse caso, você acaba se deparando com um problema diferente, que tem a ver com unsharea lógica de não ser capaz de lidar com essa configuração específica (provavelmente algo a ver com o uid efetivo e o uid real não correspondendo):

$ cp /usr/bin/unshare .
$ sudo setcap -r unshare
$ sudo chown root:root unshare
$ sudo chmod 4711 unshare
$ ./unshare -r
-bash: cannot set uid to 65534: effective uid 0: Invalid argument
-bash-4.4$ 

Observe também que a limpeza do sinalizador "dumpable" foi acionada pela execução de um binário com recursos de arquivo definidos. Se você obtiver recursos adicionais de uma maneira diferente, talvez não tenha esse problema. Por exemplo, usar recursos "ambientais" é uma boa maneira de obter recursos adicionais fora do namespace, sem ter problemas ao descompartilhar em um novo namespace de usuário.

(Infelizmente, ainda não há muitas ferramentas em torno dos recursos do ambiente. libcapapenas o suporte é fornecido no git mais recente, a versão 2.25 anterior, que é a atualmente fornecida na maioria das distros. capshé de nível bastante baixo, então não é tão fácil obtê-lo Veja aqui os detalhes sobre como usar o mais recente capshpara adicionar recursos de ambiente. Também tentei systemd-run, mas não consegui configurar os recursos de ambiente lá. De qualquer forma, algo para você analisar, se precisar de recursos, não usuário root e namespaces de usuário juntos!)