X11-app after su - leads to DISPLAY error

X11 is old enough, we forget some of the moving parts. A part of my brain says "xauth", but I don't remember the moving parts well enough to advise.

One other thing that X11 may not like, is when applications using X11 run as root. How the detection of that works (normal xauth or special case code), again, I don't know the details. All I remember is the odd application will say something about "don't run as root". The issue is X11 could be an attack surface, and elevating code which has a significant attack surface is considered to be a bad idea. Like, running Firefox as root, would be "extremely bad" :-) Even with a Snap container, who can even guess what the risk level is.

Paul

I believe you need to use xhost to add test1 as authorized to connect.

Before you do the su, issue the following command from a terminal window:

xhost +test1

Xhost is for allowing connections from other computers, so it would only make sense if test1 was the name of another computer on the network, not a user. The use of test1 with the "su" command suggests that's not the case.

It sounds like you're running into the XAUTH system.

Normally, in the home directory of the user who's running X stuff there is a file called ".Xauthority", and environment variable XAUTHORITY holds the full, absolute path to that file.

In order for user B to run X clients/apps when user A is the one who started the X server, user B must set environment variable XAUTHORITY to a file which user B has permission to read and which has the same contents as user A's ~/.Xauthority.

How you get that file and environment variable set depends on your use case. I run my web browsers, gimp, and a few other programs as a different user for security and a few other reasons. I have wrapper scripts that do the file copying, environment variable setting, and environment variable preservation across sudo and/or su. For the way I do all that, user B's only reason for existence is to run browsers and such for user A, and it's important that user A have write permission to user B's home directory by means of the g+w permission bit.

HTH

make sure xauth is installed. you'll probably just have to do as your normal user: xauth list $DISPLAY

then use xauth add that output into your su/sudo user's .Xauthority file

Xauth uses cryptographic tokens -- called MIT magic cookies -- to authenticate X11 client applications with the X11 display server that you want to connect to.

The MIT magic cookies are per user.

Conversely xhost is per host.

So if you want more granular than an IP level, you want to use xauth.

I am using something like the following to run Firefox and Thunderbird remotely using X11 across the network to display on what is effectively an X11 display server.

xauth extract - ${HOST}${DISPLAY} | ssh user@remote "xauth merge -; thunderbird ${@}"

N.B. I'm *NOT* using SSH's X11 forwarding. The X11 traffic travels outside of / parallel to the SSH stream. SSH is only used to import the current MIT magic cookie and to launch the thunderbird binary. I could just as easily log into a serial console on the remote system and launch the thunderbird binary, assuming I had the MIG magic cookie in place.

It seems like the MIT magic cookie change each boot / time I start the X11 display server. But, for simplicity, I extract the MIT magic cookie from the X11 display server and import it on the remote X11 client system each time I launch the thunderbird binary.

${HOST} is the FQDN of the X11 display server as known internally on my network. ${DISPLAY} is :0.0 for the first display on the X11 display server.

Hi,

maybe there's a way around wrapper scripts? I am wondering, why on Redhat-based systems like Mageia there is no need for that, instead all this is done in background.

What I found out is, that when switching 'su - newaccount', then

- a file ~/.xauth* (e.g.: .xauthOa9EpX) is automatically created (by su? by pam?)

- and when either starting x-app like xclock, so this works, or

- deleting this .xauth* and starting x-app, then above error occurs

This looks like su does all this "wrapping" automatically, as long as it is confugured adequately. Maybe also systemd plays some role here.

Does anyone have more details here? I am asking, because life would be easier, if this runs automaically :-)

Thanks!

Best regards,

Markus

This suggests that the original problem may have been su'ing to a user with no home directory, or one that the user has no permissions for, so this file cannot be created.

Probably with this:

Hi, good point, indeed, but on Mageia, where this works, I can switch freely via su - test... betweeen test* accounts. Directory /home/ lists like

drwx------ 9 test test 4,0K Dez 9 12:56 test/ drwx------ 2 test1 test1 4,0K Dez 7 16:46 test1/ drwx------ 2 test2 test2 4,0K Nov 4 20:10 test2/ drwx------ 10 test3 test3 4,0K Dez 9 11:24 test3/ drwx------ 2 test4 test4 4,0K Nov 21 14:45 test4/

So, the root cause may be located somewhere else.

BR,

Markus

This can also happen if the user previously used "su" to become root and ran X leaving the auth file owned by root.

Always use "su - root", which can be shortened to just "su -". Don't use just "su". See

Regards, Dave Hodgins

I'm not at all surprised.

The underlying -- so called -- problem has been well known and understood by many in the Unix community for a long time.

In short, don't give untrusted people / apps / things access to your X11 display server.

Not enabling `su -` in and of itself tends to come from a different place, mostly one of trying to avoid the existence of the super user; UID / GID of zero.

avoiding / denying super user (root) is a completely different discussion.

That being said, not going out of their way to enable cross user X11 access is probably somewhat intentional. Or at least insofar as choosing to have people enable it if they want it, ostensibly assuming that they understand the risks involved with doing so.

If an X11 client application can access an X11 display server, then said X11 client application can take a screen shot of said X11 display server. They can also read keys / mouse or worse inject keys / move the mouse.

No, not really. The key thing to remember is that *any* *access* /to/ /an/ /X11/ /display/ /server/ is tantamount to *FULL* *ACCESS* /to/ /an/ /X11/ /display/ /server/.

With that in mind, it is critical to clarify what is the X11 display server in each context.

Things like Xvnc and Xnest (whatever their actual names are today) provide a /new/ /and/ /separate/ /X11/ /display/ /server/. As such an application that has access to X11 display server :10 doesn't inherently have access to X11 display server :0.

The use of separate X11 display servers is critical.

With this in mind, you should be able to relatively safely run a virtual X11 display server via Xvnc / Xnest / etc. and have less trusted applications use it as their DISPLAY. Then use the proper viewer to cause things on the virtual X11 display server to appear on your physical X11 display server.

Things like Xvnc have the VNC protocol in separate / isolate the :0.0 X11 display server and the :10.0 X11 display server. This isolation barrier makes it MUCH more difficult for things to pass through. What's more is that Xvnc, et al. usually have much more control over what can and can't pass through the protocol divide.

I remember reading about people running multiple X11 display servers akin to virtual terminals (Control) Alt-F#. Wherein things on different X11 display servers, which happen to use the same display hardware at different times, have separate data and are much more isolated from each other.

Or shut everything else down while doing private stuff. It's hard to prevent screen scraping and key logging. If someone can get a keylogger into one account they can probably get it into all accounts.

One important thing to think about when thinking about security is "what is the threat" - if screen scraping and key logging are the threat then a dedicated session is a good answer, if browser hacks are the real threat then a separate browser is all you need.

Always remember the only totally secure computer is turned off, in a safe, buried in concrete with nobody alive who knows where it is. All else is a compromise between security and usability,

Since around the release of X11.

Yes exactly - X11 was designed with a politer more considerate set of network users in mind (inside universities) - people who might play a prank (run Xroach on all X displays in the lab or play strange noises quietly through network audio[1]) but would never intend harm and would (mostly) carefully avoid looking at private information or at least not do anything with it but giggle.

It was a different world, the internet has spread to far less pleasant people since then.

Providing any access to an X11 display server is tantamount to a key / screen logger. It's actually worse than /just/ a logger in that it can be a writer too.

This is true, and there are applications which depend on it.

One way to isolate applications completely would be to run each application in its own VM with its own X11 display (or Wayland) all displayed in a real X11 display that does nothing but run VNC viewers to the VMs. Nothing but a minimal window manager that launches VM sessions runs in the real X11 display. This does require users to be able to launch VMs - preferably ones that cannot be accessed by other users, if needs be a setuid tool could be used I suppose.

Hi everyone,

I have suspected pam authentication already, and in the meantime I compared Mageia and Raspbian more deeply regarding the entries in /etc/ pam.d.

I found out, that adding this line

session optional pam_xauth.so

to the front of /etc/pam.d/su

solves this issue. I've also tested this on Ubuntu successfully.

Now, after su - newuser, invoking an app for X11, like xclock, makes this window open and working.

Finally, big thanks to all of you for this wonderful and highly interesting discussion!

Nevertheless, it turned out to be a good idea to always handle X / desktop sessions with care.

Thanks again, best regards,

Markus

I'm not convinced that VMs and the ability to start them are required.

I think you could get away with containers that each have their own virtual X11 display server -- Xvnc for the sake of discussion -- would likely suffice.

You can get quite close running each application as separate users on the same system. Wherein each application has it's own virtual X11 display server (Xvnc).

But yes VMs will provide more isolation than containers which will provide more isolation than separate users. It's all a question of finding the balance for what is wanted vs what is needed and what resources are available.

My personal goal is so that one application; e.g. Firefox, running as a dedicated user doesn't have access to all of my personal files that my are accessed as my primary user.

Once you start going down the road of separation of the X11 display server from the X11 client applications, options start opening up, e.g. running on different systems, OSs, architectures, etc.

Grant. . . .

Hi,

Aside: I wouldn't call this "authentication" in this context. PAM has grown to do more things than just "authentication". The very fact that you are using the "session" module (?) supports that this isn't an authentication feature.

PAM is a very good place to do a lot of things to help streamline things related to client logins.

N.B. My understanding is that the order of lines in PAM is important.

-- You are probably safe following another distro as a sample. But don't sort the lines or anything like that.

Nice work.

:-D

:-)

Absolutely!

I think it's even better to have some idea that there is complexity behind it and that there might be more to look up if / when you have need to tilt at the X11 shaped wind mill.