I wanted to open an application today as the Postgres user while logged in as my normal user account. I know that dropping access control to the xserver can be a bit of a security risk but I also don’t like flicking between users to achieve a task. I don’t mind opening an xterm but logging in and out of xwindows is not much fun.
Anyway to get an application working using the insecure method we can do the following. User A is the main user and you want user B to be able to open an app in users A’s session.
A@machine:~$ xhost +
A@machine:~$ su – B
password *********
B@machine:~$ export DISPLAY=:0.0
B@machine:~$ /path/to/application/
This was easy but I don’t like using
A@machine:~$ xhost +
and allowing everyone access. This is not smart so I decided to see if there is a more secure method that avoids this. Having a read of the xhost manual I found out that I could limit access on a per host or per user basis as follows
A@machine:~$ xhost +B@
which gives me a lovely error message as seen below. I have tried various different methods but I get the same error message.
B@ being added to access control list
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 109 (X_ChangeHosts)
Value in failed request: 0xfe
Serial number of failed request: 7
Current serial number in output stream: 9
so it would appear to me that there is something amiss somewhere. I googled for quite a while to see if I could find a definitive answer. No joy, they all recommended using xhost + which is not what I want to do.
Simple things like this can be such a bloody chore under Linux. I know, I know stop bitching and start patching.
Anyway. I can remember doing something similar to what I want with ssh so I had a look at the man page and found the following snippet
-X Enables X11 forwarding. This can also be specified on a per-host
basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
user’s X authorization database) can access the local X11 display
through the forwarded connection. An attacker may then be able
to perform activities such as keystroke monitoring.
This meant that I could do the following.
A@machine
A@machine:~$ ssh -X B@machine
password ********
B@machine:~$ /path/to/application
and I get the window displayed. Remember that you need to edit the
/etc/ssh/sshd_config
files and set X11forwarding to yes. This is more secure than using xhost + but still not ideal but good enough for what I want it for.
Kernel Oops
I got a series of kernel oops when using SATA on an MSI K8T Neo motherboard. I have written a short article on what I did to get it working. Luckily for me it turned out to be a solvable problem or at least it hasn’t oopsed on me since.