SELinux - timeout in locking authority file .Xauthority

Może się zdarzyć że po zalogowaniu ssh -X dostaniemy komunikat:

Last login: Thu Mar 24 21:41:30 2016 from 10.99.0.2
/usr/bin/xauth:  timeout in locking authority file /opt/ibpmusers/scichy/.Xauthority

I nie działa nam prawidłowe ustawianie zmiennej środowiskowej DISPLAY.

Założenie

W naszym przypadku główny katalog z katalogami domowymi użytkowników nie jest domyślny (/home) ale /opt/ibpmusers.

Żeby zweryfikować problem należy po zalogowaniu wydać polecenie strace xauth list. W odpowiedzi możemy dostać:

[scichy@localdevdb ~]$ strace xauth list
 #...
 open("/opt/ibpmusers/scichy/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 nanosleep({2, 0}, 0x7fff78965d20)       = 0
 write(2, "xauth:  timeout in locking autho"..., 76xauth:  timeout in locking authority file /opt/ibpmusers/scichy/.Xauthority
 ) = 76
 exit_group(1) 

Możemy sobie zadać pytanie: Permission denied? No ale jak to? Przecież to mój katalog domowy, wszystko jest moje... Ale to nie prawda. Za zarządzanie uprawnieniami może być odpowiedzialny mechanizm SELinux (Security-Enhanced Linux (w skrócie SELinux) – zestaw modyfikacji Linuksa oraz sposobu przydzielania zasobów dla aplikacji). Sprawdzamy, czy jest włączony SELinux by się upewnić, że mamy rację:

[scichy@localdevdb ~]$ egrep -e '^SELINUX=' /etc/selinux/config
SELINUX=enforcing

SELinux jest włączony, a zatem faktycznie jest on odpowiedzialny za przydzielanie uprawnień aplikacjom. Przechodzimy do katalogu, w którym się znajduje nasz głowny katalog (/opt/ibpmusers) i sprawdzamy jakie są uprawnienia na katalogach użytkowników:

[scichy@localdevdb ~]$ cd /opt
[scichy@localdevdb opt]$ ls -aslZ ibpmusers/
razem 28
drwxrwxrwx. root        root       unconfined_u:object_r:home_root_t:s0 .
drwxr-xr-x. root        root       system_u:object_r:home_root_t:s0 ..
drwxr-xr-x. ttesteusz   developers unconfined_u:object_r:home_root_t:s0 ttesteusz
drwxr-xr-x. ldeveloper  developers unconfined_u:object_r:home_root_t:s0 ldeveloper
drwxr-xr-x. scichy      developers unconfined_u:object_r:home_root_t:s0 scichy

Widzimy, że uprawnienia są nieprawidłowe: unconfined_u:object_r:home_root_t:s0 a powinny być unconfined_u:object_r:user_home_dir_t:s0. Jako użytkownik uprzywilejowany root musimy to zmienić poleceniem chcon:

[root@localdevdb opt]# chcon -u unconfined_u -t user_home_dir_t -r object_r /opt/ibpmusers/*

To nie działa

Ktoś napisał, ze trzeba wykonać polecenie restorecon /opt/ibpmusers/*, ale to nie dało spodziewanego efektu (uprawnienia zostały zmienione, ale nie na takie jak powinny):

[root@devdb2 opt]# restorecon /opt/ibpmusers/*
[root@devdb2 opt]# ls -aslZ ibpmusers
razem 28
drwxrwxrwx. root        root       unconfined_u:object_r:usr_t:s0   .
drwxr-xr-x. root        root       system_u:object_r:home_root_t:s0 ..
drwxr-xr-x. ttesteusz   developers unconfined_u:object_r:usr_t:s0   ttesteusz
drwxr-xr-x. ldeveloper  developers unconfined_u:object_r:usr_t:s0   ldeveloper
drwxr-xr-x. scichy      developers unconfined_u:object_r:usr_t:s0   scichy

Typ musi być user_home_dir_t a nie usr_t.

Teraz wszystko powinno działać. Jeśli nadal nie działa, znowu robimy polecenie strace xauth list i sprawdzamy co tam jest nie tak - stosujemy się do wskazówek, które uzyskamy na ekranie.