Forum Debian Users Gang

Zgłębiając temat, znalazłem takie ciekawe info:

> 1)does xhost set the DISPLAY variable ?

No, in fact, xhost needs the DISPLAY variable already set so that it
knows which display to try and connect to to change access control.
xhost needs some way to authenticate itself to the X server so X can
trust that it's a legit user trying to change the access control.  If
you open up X to all local users by using something like xhost
+localhost or xhost local: then any local user could take over your
display and use xhost to disable your access to it.

> 2)does xhost local: also uses the tcp thingie or use it the x socket thingie ?

local: allows anyone to access the X server through unix domain sockets.
+localhost allows all local programs to access X though tcp sockets.
Normally tcp sockets are only used for remote connections since they are
slower than unix sockets, but unix sockets only work on the same
machine.

> 3)what must i put in the .Xauthority file to make the screensaver work
> with having to use xhost ?

When X first logs in to a user, it creates the .Xauthority file in that
users home directory and fills it with a random string called a
MIT-MAGIC-COOKIE.  Any X client, by default, reads that file to see what
the cookie is then sends it to the X server to authenticate itself.
Anyone who can read that file can access the display so that file is
normally only readable by the user who logged in, though root can always
read it because root is god.  When you run an X program as a different
user, it will look in that users home directory for the .Xauthority
file and so won't be able to find the right cookie unless you used the
xauth command to give that user the cookie ahead of time.  By setting
the XAUTHORITY environment variable to some other file, it will check that
file for the magic cookie instead of the current users home directory.
This is useful when running a command as root that you want to access a
normal users X server.  This is a much more secure way to allow access
to X than using xhost since you know what users are able to access X,
not just which computers, which may have multiple users on them.

In summary, don't touch xhost, just use:

XAUTHORITY=/home/user/.Xauthority xscreensaver

or you can use xauth to extract the magic cookie and then import it into
the correct users .Xauthority file.  As the user of the X server:

xauth extract my-cookie-file $DISPLAY

Saves the magic cookie to a file called my-cookie-file for the current
display.  Then as the user who want to access the X display:

xauth merge my-cookie-file

Adds the cookie stored in my-cookie file to the current users
.Xauthority file.  Now user B can open an X application on A's X server.

Oh, and don't run xscreensaver as root EVER!  Instead, if you're really
paranoid about security, make a user who can access any of your files
whose sole purpose is to run xscreensaver then use that user to run it.
This is still not that much more secure since any user that can access
an X server can essentially take it over and control your mouse and
keyboard doing what ever they want, like openning an xterm on your
display and running the passwd command to change your passwd.  Now they
just gained access to all your files as well.[/quote]
http://lists.freebsd.org/pipermail/freebsd-questions/2005-February/075394.html

Próbowałem dopisać sobie w /etc/profile :

Kod:

export XAUTHORITY=/home/morfik/.Xauthority geany

ale to kompletnie nie wpływa na to jaką aplikację mogę odpalić — można wszystkie, a dopisek "geany" na nic nie wpływa — zachowuje się tak samo jakby go nie było. Ale pomijając ten szkopuł to działa dobrze ale tylko w przypadku gdy istnieje jeden user, ten wymieniony w ścieżce. Gdy chciałem utworzyć morfik2 i zalogować się tylko do systemu przez lightdm, to już mnie system nie chciał przepuścić. Po zakomentowaniu tego wpisu, bez problemu mogłem się zalogować.

Dodając powyższy wpis w /root/.zshrc (może być i .bashrc, jestem w trakcie zmiany shella) userzy mogą się logować bezproblemowo, obaj mogą się logować na roota, przy czym tylko jeden z nich może odpalać aplikacje graficzne. Niby fajna rzecz, tylko pytanie, a gdybym tak miał 100 użytkowników w systemie i 2 adminów? Jak 2+ użytkownikom zezwolić na używanie graficznych appsów na roocie?

Próbowałem też użyć do tego celu xauth z extract i merge i niby jest ok. Problem w tym, że tylko na czas zalogowania się. Widać ten cookie jest tworzony przy każdym zalogowaniu się na x-y przez jakiegoś usera i by mieć możliwość odpalania graficznych aplikacji z roota, trzeba by ciągle powtarzać kroki z wydobywaniem ciasteczka i dodawaniem go do .Xauthority w katalogu roota. Da radę to jakoś zautomatyzować?

Oczywiście to wszystko jest przy założeniu, że na roota loguję się za pomocą "su -".