We need the ability to change the default "umask" and "chmod" of our Pipelines builds (PTGS-5190)

Issue #19053 new
Gabriel Marcolino staff created an issue

In order to match our security practices, we would like to have the ability to set, on the "Build Setup", different values to the "umask" and "chmod" variables.

This impact our deployments since, we need to manually update the permission of the files and folders before we deploy our builds, in order to avoid malicious scripts in our application directory.

Comments (2)

  1. Jonas Moura

    Com relação as permissões recursiva, já utilizo a mesmas para contornar o problema do "umask" definido no "Build Setup".
    Segue o que utilizo:

    find ${PROJECT_WORKSPACE} -type d -exec chmod 755 {} \;
    find ${PROJECT_WORKSPACE} -type f -exec chmod 644 {} \;
    

    Com essas duas linhas eu resolvo o problema, porém dependendo da quantidade de arquivos que tem meu projeto, isso pode ser um pouco demorado. Por isso sugeri a melhoria de ser implementado a funcionalidade de definir o "umask 000" e o "chmod 777" utilizados no "Build Setup", fazendo com que todos arquivos sejam copiados (clonados) com as permissões corretas, pensando pelo lado da segurança.
    Além da segurança, algumas ferramentas/utilitários do GNU Linux, solicitam que arquivos de configuração não tenham permissão de escrita para o grupo e outros, mas sim apenas para o usuário owner do arquivo. Um exemplo é o logrotate (utilizado para retenção e reciclagem dos logs das aplicações/aplicativos), onde necessito definir uma linha via script para que deseja definida as permissões corretas, como abaixo:

    chmod 644 /etc/logrotate.conf /etc/logrotate.d/*
    

    As permissões deste arquivo "/etc/logrotate.conf" são clonadas no "Build setup" com a permissão 666, fazendo com que o logrotate dê um erro, pois as permissões são inseguras. Isso não acontece apenas como o logrotate, mas com outros mais. A permissão 666 para arquivos e 777 para pastas, não é uma prática de segurança correta.

  2. Jonas Moura

    Regarding the recursive permissions, I already use the same ones to work around the "umask" problem defined in the "Build Setup".
    Here's what I use:

    find ${PROJECT_WORKSPACE} -type d -exec chmod 755 {} \;
    find ${PROJECT_WORKSPACE} -type f -exec chmod 644 {} \;
    

    With these two lines I solve the problem, however depending on the amount of files that my project has, this can be a little time consuming. So I suggested the improvement of implementing the functionality of setting the "umask 000" and "chmod 777" used in the "Build Setup", causing all files to be copied (cloned) with the correct permissions, thinking for the security side .
    In addition to security, some GNU / Linux tools / utilities require that configuration files not have write permission for the group and others, but only for the user owner of the file. An example is logrotate (used for retention and recycling application / application logs), where I need to define a line via script so that I want to set the correct permissions, as below:

    chmod 644 /etc/logrotate.conf /etc/logrotate.d/*
    

    The permissions of this file "/etc/logrotate.conf" are cloned in the "Build setup" with the permission 666, causing the logrotate to give an error because the permissions are insecure. This happens not just as logrotate, but with others as well. Permission 666 for files and 777 for folders is not a good security practice.

  3. Log in to comment