Eu tenho feito mais leituras e testes. Eu tenho uma solução, se não uma explicação completa.
- Faça login no Linux como
currentuser
- inicie
bash
terminal - xauth list $ DISPLAY
-
mint/unix:0 MIT-MAGIC-COOKIE-1 7b00a8e53b8d9e579c2eaf5009561fa4
-
- alterar o nome do usuário
-
su -
otheruser
-
-
XAUTHORITY=/home/
otheruser
/.Xauthority
-
xauth add mint/unix:0 MIT-MAGIC-COOKIE-1 7b00a8e53b8d9e579c2eaf5009561fa4
-
xeyes
As duas grandes diferenças são os passos # 4 e # 5. Olhando para a página do manual su
, revela:
If --login is used, the $TERM, $COLORTERM, $DISPLAY, and $XAUTHORITY environment variables are copied if they were set.
Eu serei honesto e só encontrei (a importação de) essa informação depois que consegui que o xeyes
funcionasse. Então, a primeira coisa a ser feita é usar
-
su
-
otheruser
Usando o único traço, significa que o ambiente é definido por scripts e não copiado do currentuser . Por padrão, a proteção do arquivo .Xauthority
é definida como acesso somente proprietário:
-
-rw------- 1
currentuser
currentuser
54 Dec 26 23:21
**.Xauthority**
Portanto, quando o XAUTHORITY
aponta para o arquivo currnetuser
, há uma falha na Abertura do Arquivo. Assim, a segunda mudança:
-
XAUTHORITY=/home/
otheruser
/.Xauthority
Lembre-se, essa é uma das variáveis de ambiente copiadas com o comando
su
.
Eu suspeito que apenas a segunda mudança seja necessária, para o meu uso eu queria um 'bom' logon para outro usuário , como se ele estivesse logado na área de trabalho ou via ssh. / p>
Ponto final de vantagem; como a variável DISPLAY
também é copiada, não é necessário definir e exportar DISPLAY
que seria necessário com um loopback usando ssh
.
progredindo
Sempre que você fizer login com su ; o primeiro passo é definir a variável de ambiente XAUTHORITY
para apontar para o local
-
~/.Xauthority
.
No final, era a variável de ambiente: XAUTHORITY
apontando para o *currentuser*
que fazia as coisas não funcionarem. Espero que a próxima pessoa descubra que economizou muito tempo!