Propriedade de .Xauthority transferida para raiz

De alguma forma, enquanto brincava com o LightDM e o Webkit Greeter, a propriedade do .Xauthorityarquivo no meu diretório pessoal foi atribuída ao usuário root e não pude fazer login porque não tinha privilégios para bloquear o arquivo.

Consegui recuperar a propriedade do arquivo e consegui entrar novamente. (Após várias horas de reinstalação do LightDM e da recepção)

Então agora tudo está funcionando bem novamente. Mas eu gostaria de saber como isso aconteceu. Isso é um bug no LightDM ou no Webkit Greeter ou algo mais?

permissions login

— s3lph
fonte

Respostas:

Quase certamente não, não. Você iniciou uma sessão X como root (não sabe como conseguiu isso) ou simplesmente usou touchou escreveu .Xauthoritycom ele sudo. Para mais detalhes, você teria que explicar o que estava realmente fazendo.

Da próxima vez, não reinstale nada, apenas exclua o ~/.Xauthorityarquivo, ele será recriado automaticamente na próxima vez que você efetuar login:

sudo rm ~/.Xauthority

Então faça o login normalmente.

— Terdon
fonte

Para descobrir onde estava o problema sudo startx, corri uma vez , o que funcionou. Depois de alterar a propriedade do arquivo, eu poderia entrar novamente. Então, iniciar o X como root apenas corrigiu o problema original?

— s3lph

@the_Seppi não, a execução do sudo startx iniciou uma sessão X que era de propriedade do root, que era o proprietário .Xsessione, portanto, era possível fazer login. Você alterou a propriedade que permitia ao usuário fazer login novamente. Da próxima vez, basta excluir o arquivo, como eu disse, ele é recriado automaticamente no login, não há sentido em "consertar" suas permissões.

— terdon

Mas isso consertou. E eu não fiz mais nada para .Xauthority. Btw. qual é o objetivo deste arquivo?

— S3lph

@the_Seppi sim, foi corrigido. O .Xauthorityarquivo é basicamente um número mágico usado para identificar o proprietário de uma sessão X para que outras pessoas não possam sequestrá-lo. Se você estiver executando uma sessão X e eu estiver conectado à mesma máquina, não poderei acessar sua sessão X a menos que eu seja o proprietário do .Xauthorityarquivo. É criado sempre que você efetua login, a menos que exista. Então, sim, alterar as permissões para seu usuário irá corrigi-lo, mas simplesmente excluí-lo.

— terdon

Eu tive esse mesmo problema; ficou assim tentando executar o startx como root depois de tentar recuperar de uma atualização incorreta que desativava o bluetooth. Estou tentando há horas recuperar a GUI. Acontece ser super simples! Exclua todos os arquivos de bloqueio .Xauthority, exclua o arquivo .Xauthority e reinicie. <rant> São pequenos segredos como esse, que são tão difíceis de encontrar se você não sabe (ou faz muito tempo desde que você era), que atualmente fazem do linux uma má escolha para muitas pessoas que poderiam usá-lo. </rant>

— hlongmore

Isso aconteceu comigo também. Eu acho que isso pode ser causado pela execução

sudo graphic_application

ao invés de

gksudo graphic_application

para alguns aplicativos (desconhecidos). Há um parágrafo na página de ajuda do sudo sobre isso ... role para baixo até "Sudo gráfico".

Veja também Qual é a diferença entre "gksudo nautilus" e "sudo nautilus"?

— Rmano
fonte

Isso não deve afetar o .Xauthority, criado quando a sessão X é iniciada, não será afetado pelos lançamentos subsequentes de aplicativos da GUI.

— terdon

@terdon você está certo --- a menos que você use startx ou similar. Eu estava brincando com o Xnest quando fui mordido por ele, provavelmente erro do operador.

— Rmano 20/03