Estou tentando definir o contexto do samba no diretório com o seguinte comando e não tenho certeza sobre o que é este erro, mas não consigo definir o contexto no diretório.
semanage fcontext -a -t samba_share_t "/common(/.*)?"
Lançado da seguinte forma:
Full path required for exclude: net:[4026532292].
O erro que você vê não é causado pela aplicação do contexto samba_share_t no diretório /common . Você ainda pode tentar restorecon -R /common e verificar se o contexto do selinux está de fato alterado. Acredito que o erro tenha origem em configurações anteriores.
Já faz mais de um ano desde que isso foi perguntado, mas não encontrei uma resposta on-line. Vamos consertar isso para a próxima pessoa. :)
Esses erros ocorrem porque algo criou namespaces de rede em sua máquina. Se você olhar para a saída de mount , verá um tipo de sistema de arquivos proc montado em algum lugar (provavelmente sob / run ou / var / run) com esse número. No entanto, se você olhar para /proc/mounts como faz o restorecon (e semanage), verá o mesmo sistema de arquivos com "net: [xxx]" como o ponto de montagem. Infelizmente, restorecon / semanage não tem idéia de como lidar com isso; eles apenas veem um caminho que não começa com / e emite um erro.
Por que isso acontece? Se você verificar a fonte restauradora , verá esse restaurorecon adiciona automaticamente entradas de exclusão para pontos de montagem que não possuem o conjunto de opções de montagem de legenda. O mesmo acontece com a semanage. A opção seclabel deve ser gerenciada pelo SELinux, eu acho. O que isso faz é indicar que o sistema de arquivos usa xattrs para armazenar os atributos do SELinux. É por isso que esses sistemas de arquivos estão sendo excluídos: não faz sentido tentar definir o contexto em arquivos quando o sistema de arquivos não suporta contextos SELinux.
Ótimo. Como você conserta isso? O selinux_restorecon() syscall inclui um sinalizador - SELINUX_RESTORECON_IGNORE_MOUNTS - que o instrui a não se incomodar com essa verificação, mas não parece haver uma maneira de dizer aos programas de restauração ou semanage para fazerem o mesmo. Portanto, uma opção é escrever seu próprio programa restorecon, que faz com que o syscall com o sinalizador ignore os rótulos de montagem. Isso é uma dor. :) Uma opção mais fácil que eu gosto é apenas usar um contexto de montagem para esconder os pontos de montagem que você provavelmente não está interessado em percorrer de qualquer maneira. Os contextos causam o problema, então por que não corrigi-lo com contextos também?
sudo unshare -m sh
umount $( mount | awk '$3~/netns/{print $3}' )
restorecon -rv /some/file
exit
Use unshare -m para criar um novo namespace de montagem e execute sh (escolha seu shell favorito aqui) nesse namespace. Em seguida, desmonte os sistemas de arquivos ofensivos. No meu caso, com o Docker fazendo isso, todos os sistemas de arquivos incluem netns (e eu não tenho sistemas de arquivos com essa cadeia), então eu apenas removo os pontos de montagem correspondentes e os passo para desmontar. Alguém pode precisar encontrar e desmontar de maneira diferente, mas a ideia é a mesma. Como o unshare -m é padronizado para um namespace de montagem particular, a desmontagem não afeta mais nada no sistema - basicamente oculta as montagens desse processo. Nesse ponto, eu tenho um shell onde esses sistemas de arquivos não são visíveis. Assim, quando o restaurorecon inspeciona /proc/self/mounts (tecnicamente abre /proc/mounts , mas para compatibilidade com versões anteriores é um link para /proc/self/mounts em sistemas que suportam espaços de nomes de montagem) no espaço de nomes herdado do shell, é capaz de executar sem problemas .
Se você se encontrar fazendo isso com frequência, provavelmente faria sentido colocar o umount e o restorecon em um shell script e apenas executá-lo com o restorecon ao invés de iniciar um shell.