Como é razoável fazer um trabalho ansible em sistemas com umask restritiva?

Question

Q1. Se você configurar root com umask restritiva, isso afetará os arquivos criados quando você executar o ansible, certo? (A menos que você diga ansible para garantir um modo específico aka.).

A1. Parece, ansible não redefine automaticamente o umask.

• Usando ansible para atualizar ansible em envronment com umask restritiva
• [ansible-project] Definindo temporariamente umask

Q2. O que podemos concluir disso?

1. Existe uma maneira de escrever papéis ansiosos de que eles nunca dependerão da umask?
2. Existem desvantagens em escrever um papel ansioso para trabalhar sob essa restrição?

Answer 1

Ansible agora responde a essa pergunta adicionando uma opção umask , a módulos como os mencionados, que criam arquivos sem um modo específico.

• pip_module.html # options
• Não é possível configurar o Umask / Mode para o módulo Git # 10279 - Fechado

Não vejo grande desvantagem se você adicionar essa opção mais explícita, quando apropriado. Talvez apenas um pequeno aborrecimento ao ler o papel.

Eu noto que o módulo copy não implementa umask . Você pode especificar mode , é apenas que isso tem uma semântica ligeiramente diferente. Se você pudesse especificar umask e o arquivo já existisse (independentemente do conteúdo), seu modo não seria alterado. (Na função em que estou trabalhando, acho que é útil que o módulo de cópia tenha me feito pensar sobre isso).

Observo que a mensagem original menciona permissões de quebra de pip na instalação ansible em /usr/lib/python2.6/site-packages . Certamente isso também seria um problema ao executar pip manualmente. Parece um defeito no pip ... mas diferentemente dos pacotes do sistema operacional, os pacotes pip também podem ser instalados dentro de um virtualenv , então é muito mais complexo para pip determinar a intenção do usuário. Indiscutivelmente, é mais um exemplo de um problema potencialmente imprevisto de usar umask restritiva.