Auto definir permissões de gravação para arquivos recém-gerados no Linux Ubuntu

0

Estou executando um programa em um servidor Ubuntu Linux remoto. Este programa acessa os arquivos existentes do meu diretório, realiza alguns cálculos, grava novos arquivos no diretório e depois tem que acessar os arquivos que criou para executar novos cálculos. O problema que tenho é que o primeiro lote de arquivos que o programa cria só tem permissão de leitura do proprietário - o programa não pode executá-los e, em seguida, expira com um erro. Existe uma maneira de garantir que todos os arquivos gravados em meu diretório tenham permissões de leitura, gravação e execução públicas (rwxrwxrwx)? Eu não posso modificar o script do programa de qualquer maneira e eu não posso parar o programa uma vez iniciado, então minha única opção é fazer isso via Linux.

Eu dei uma olhada nas perguntas anteriores, mas não consegui ver nada que tratasse desse problema específico.

Agradecemos antecipadamente por qualquer sugestão :)

    
por Magpie101 14.04.2017 / 18:39

1 resposta

2

Existem várias maneiras de obter o que você descreve usando o shell, mas tudo depende do tipo de acesso que você tem e do nível de acesso das pastas em questão e do acesso ao shell.

Pelo que entendi, você quer mudar o comportamento do servidor em relação a esses novos arquivos gerados. Mas depende do usuário rodar o script ou aplicação, sua relação com o usuário do shell ou ftp ... o fato é que o que realmente sabemos sobre o seu problema ainda não está completo.

Você poderia, por exemplo, atribuir a propriedade da pasta ao usuário do aplicativo, mas poderia causar problemas ao usuário do shell ou ao usuário do ftp se eles não fossem os mesmos.

Para isso, você pode usar:

chown -R user:group /[path-to]/myfolder

onde [path-to] deve ser alterado para o caminho da pasta e myfolder para a pasta real na máquina, o usuário e o grupo devem ser alterados, respectivamente, para o usuário e grupo do usuário que executa o aplicativo ou script. Se a sua pasta era, por exemplo, "app" e está no caminho / var / www / na máquina remota, e o aplicativo é executado pelo usuário www-data, então deve ser

chown -R www-data:www-data /var/www/app

Mas, como eu digo, pouco sabemos sobre os detalhes. Então pode ser que o problema seja gerado por uma política estrita pelo administrador do servidor onde o umask algo como:

umask 333 ou pior ainda umask 377

onde as permissões resultantes são algo como r - r - r-- ou r -------- mas para lidar com isso você pode colocar umask temporária em seu aplicativo, ou configurá-lo no env para o usuário do aplicativo ... mas eu realmente acho que isso é realmente improvável (diga-me se você precisa de algo assim para expandir nesta opção)

outra forma é não conceder totalmente a propriedade ao usuário do aplicativo, mas usar um grupo ao qual o usuário do aplicativo pertença e ativar o sinalizador s para permitir que todos os arquivos do diretório sejam criados automaticamente com permissões de concessão especiais no grupo.

altere primeiro a propriedade do grupo da pasta, como:

chown -R sameuser:newgroup /[path-to]/myfolder

altere o bit sgid da pasta

chmod g+s /[path-to]/myfolder

mais sobre o sgid no link

SGID (Set Group ID up on execution) is a special type of file permissions given to a file/folder. Normally in Linux/Unix when a program runs, it inherits access permissions from the logged in user. SGID is defined as giving temporary permissions to a user to run a program/file with the permissions of the file group permissions to become member of that group to execute the file. In simple words users will get file Group’s permissions when executing a Folder/file/program/command.

Mas, de qualquer forma, se eu estou perdendo o seu ponto, considere que às vezes ajuda saber um pouco mais sobre o problema em questão. Considere expandir um pouco sua pergunta com outras informações relevantes (como o tipo de aplicativo, o que você quer dizer sobre solução de problemas com o Linux, como o usuário executa seu aplicativo ou você tem acesso ao shell?)

Espero que ajude mesmo assim.

    
por 15.04.2017 / 19:11