Por que um comando iniciado com nohup não consegue gravar o arquivo após o logout do usuário?

Por que um comando iniciado com nohup não consegue gravar o arquivo após o logout do usuário?

Estou usando o nohup para iniciar o matlab e executar um script que requer a leitura e gravação de alguns arquivos.

nohup matlab -nojvm -nodisplay -r 'MyScript'&

Isso funciona perfeitamente enquanto estou logado, mas assim que saio e faço login novamente, vejo que meu processo matlab não está mais em execução. Depois de verificar o arquivo nohup.out, encontro a seguinte mensagem de erro:

Unable to write file $HOME/matlab/my_mat_file.mat: permission denied

Parece que assim que eu saio o dono do processo matlab muda e ele não tem mais acesso aos meus arquivos. Como posso evitar que esse erro ocorra sem alterar as permissões do arquivo, por exemplo, concedendo permissões de gravação a todos?

Esta mensagem de erro também aparece ao usar a tela GNU. Se eu executar ls -al $HOMEdentro da minha sessão de tela GNU antes de sair, terei

comando antes de sair

Eu me separo da sessão da tela GNU, efetuo logout, login e reconecto à sessão da tela apenas para descobrir que perdi o acesso aos arquivos aos quais eu costumava ter acesso dentro da tela. A saída de ls -al $HOMEé agora

comando após sair

Intrigante, não é?

Responder1

Tem a ver com autenticação.

Começarei com alguns conceitos sobre tickets e tokens e como o sistema de autenticação Kerberos e o AFS os utilizam. No final, a resposta à minha pergunta ficará clara: não tenho permissão para escrever no arquivo simplesmente porque meu token AFS foi removido no logout. Dito isto, a solução para o meu problema foi incluir no script matlab algumas linhas que determinam se o token existe ou não, criá-lo caso não exista. Como isso foi feito exatamente conclui a resposta.

Autenticação

Fornecer um sistema de arquivos distribuído, acessível de qualquer lugar, implica um sistema de segurança robusto. É por isso que o AFS possui um sistema de autenticação forte, integrado ao sistema de autenticação Kerberos.

A autenticação no AFS é resolvida por meio de um token. Os tokens concedem aos usuários acesso aos dados durante sua vida útil. Em muitos casos, o manuseio de tokens é contínuo, não exigindo intervenção do usuário. Porém, o usuário pode, a qualquer momento, listar os tokens emitidos em seu nome usandotokens

username@machine00 ~ $ tokens

Tokens held by the Cache Manager:

User's (AFS ID xxxxx) tokens for [email protected] [Expires Mar 20 05:10]
   --End of list--

Os tokens AFS são obtidos de um ticket identificador Kerberos. Da mesma forma que os tokens, os tickets Kerberos também identificam o usuário. Ao usar o sistema de autenticação Kerberos, o usuário recebe do KDC (Key Distribution Center) um ticket inicial denominado ticket-granting ticket. Este primeiro ticket identifica exclusivamente o usuário e permite que ele obtenha tickets específicos necessários para serviços adicionais, como os tokens AFS. Na verdade, você pode usar diretamente o ticket Kerberos para que o serviço AFS tenha o token de identificação AFS.

Na maioria dos casos, o ticket de concessão de tickets do Kerberos é obtido automaticamente durante o login do usuário. O mesmo acontece com o token inicial do AFS. Assim como os tokens, o tratamento de tickets Kerberos é, na maioria dos casos, invisível para o usuário, mas você pode listar os tickets emitidos usandoklist

username@machine00 ~ $ klist
Credentials cache: FILE:/tmp/krb5cc_V16088
        Principal: [email protected]

  Issued           Expires          Principal                 
Mar 19 19:10:11  Mar 20 05:10:11  krbtgt/[email protected]
Mar 19 19:10:11  Mar 20 05:10:11  afs/[email protected]   
username@machine00 ~ $

o cache de credenciais é o local do arquivo onde os tickets são encontrados. O Principal é o ID do usuário e basicamente resulta da combinação do nome de usuário e do domínio do Kerberos. Observe que o domínio Kerberos geralmente é fornecido em letras maiúsculas e diferencia maiúsculas de minúsculas. A seguir temos a lista dos bilhetes emitidos, com as respectivas datas de emissão e vencimento. Neste caso, o primeiro ticket ( krtbg) corresponde ao ticket de concessão de ticket no realm KERBEROS.REALM.DOMAINenquanto o segundo corresponde ao token AFS na célula afs your.system.domain(que geralmente tem o mesmo nome do domínio no qual pode ser encontrado). Outros tickets Kerberos podem aparecer na lista caso tenham sido solicitados.

Renovação de token

Quando um token AFS expira, o acesso à conta AFS não é mais possível. Os sintomas de que tal evento ocorreu variam de sistema operacional para sistema operacional, no entanto, no Unix/Linux você geralmente recebe uma mensagem de permissão negada ao tentar acessar seus arquivos:

username@machine00 ~ $ ls
ls: .: Permission denied

Quando um token expira, você precisa renová-lo. Uma maneira fácil de fazer isso é sair e fazer login novamente, pois, na maioria dos casos, a renovação do token acontece automaticamente no login. Mas acontece que às vezes sair não é uma opção, especialmente se você estiver executando algo do qual não deseja sair, e é esse o caso.

Uma solução alternativa para renovação de ingressos é utilizar kinite aklog, em sequência. O primeiro desses comandos ( kinit), que requer sua senha, permite a reautenticação do usuário e a renovação do ticket de concessão de tickets. Em seguida, aklogo comando permite obter um token AFS do ticket Kerberos. Observe que ele kinittenta obter um ticket para o principal e o domínio padrão. Caso não estejam definidos, ou se o usuário estiver utilizando um nome de usuário diferente no momento da solicitação do ticket, kinitdeverá ser utilizado como kinit <principal>@<realm>, por exemplo:

username@machine00 ~ $ kinit [email protected]
[email protected]'s Password: 
username@machine00 ~ $

O oposto de aklogis unlog, que exclui o token AFS. Da mesma forma, kdestroyremove o arquivo dos tickets, excluindo todos os tickets Kerberos.

Como isso salvou o dia e me ajudou a amar meus amigos e família

Como disse no início, conhecer esses conceitos me ajudou a entender melhor o que estava acontecendo com minha sessão de matlab. Após o logout, meu token AFS não estava mais lá e meus processos em execução não tinham mais permissão para gravar em meu volume AFS. Como, no momento, estou interessado apenas em garantir que meu script matlab continue lendo e gravando arquivos mesmo depois de sair, tive o cuidado de incluir um teste no token AFS antes de qualquer acesso ao volume AFS

ticket_status = unix('klist -s');
if ticket_status ~= 0,
   unix 'kinit [email protected] <<< "password"';
   unix  aklog
end

Como eu disse, isso vai para o script matlab e coloquei-o logo antes de qualquer comando saveou loadmatlab. O código usa o comando matlab unixpara executar seus argumentos em um shell Unix e retornar os resultados. O comando Unix klist -sé executado klistsilenciosamente, mas retorna seu status de saída. Testamos o status de saída das credenciais e solicitamos novas caso elas não existam ou tenham expirado.

informação relacionada