xsel not recognized after "su - other-account"

Question

I am new to Linux and have set up the following version of Ubuntu as a VirtualBox VM using this process:

ubuntu-20.04.3-desktop-amd64.iso

The first account created was a administrator account. I installed xsel and checked that it worked. I then created a non-administrator account and sud into it with su - non-admin-account. At that point, xsel complains:

xsel: Can't open display: (null)
: Inappropriate ioctl for device

What do I have to do to make xsel accessible after suing into another account?

Presently, I'm not interested in starting apps that launch their own client windows when su'd into the non-administrator account. I just want simple piping of standard out to the clipboard so that I can retrieve it in Vim or the Bash command line using Shift+Ins, e.g., echo dog | xsel -ib or echo dog | xsel -ip.

My current plan is to write or redirect to (say) /tmp/tmp.txt to pass text between a user that logged in from a login screen versus one that was sud to. I'm used to Cygwin's behaviour, where the clipboard is shared regardless of which account a terminal is started under.

---

Troubleshooting

I get the same behaviour if I log into the non-administrator account and su to the administrator account. xsel works in the non-administrator that I log into, but not the administrator account that I su to.

Essentially, xsel doesn't work after an su.

As per the comments, I looked at this problem's answers. I don't recognize the problem description, as the error messages are quite different, so someone looking based on error messages won't recognize that question. Furthermore, I don't understand the answers. The bit that looked like it might apply to my solution was xhost +localhost, but it didn't work because the syntax is wrong, at least for the Ubuntu version I'm using. I post the syntax that does work in my answer below.

I think that before that above cited page can even remotely inform someone, you have to know that the problem is the lack of permission for an account to access the X server. For example, if you come from a background of using Cygwin's X-windows, you would probably not guess this because the problem doesn't manifest itself there.

Answer 1

Based on waltinator's comment, I found this page on using xhost. From that information, I found the following to work:

# Log into admin-username from the login screen,
# then issue:
$ xhost +SI:localuser:nonadmin-username

   localuser:nonadmin-username being added to access control
   list.

$ xhost

   SI:localuser:nonadmin-username
   SI:localuser:admin-username

$ su - nonadmin-username
# Enter password when prompted

# Match DISPLAY to its value in the admin account
$ export DISPLAY=:0

$ ls | xsel -ip # Use PRIMARY selection e.g. X-windows mouse highlighting
$ ls | xsel -ib # Use CLIPBOARD buffer e.g. Windows's Ctrl+C/X/V
$ exit # Exit the "su" session

# Paste then works in admin account as expected.
# To test the PRIMARY selection:
$ cat # In admin account
# Paste using middle mouse button or Shift+Ins
Ctrl+D to end input into "cat"

A useful alternative to adding users one-at-a-time is xhost +local:, which allows any local user to open client windows. This implies that you trust everybody logged on to the machine. Therefore, this should only be done in controlled environments, such as single-user machines.

In many environments, the PRIMARY selection can also be pasted in [G]Vim from register *.

Similarly, the CLIPBOARD buffer can often be pasted in [G]Vim from register +, or from any other app that uses Ctrl+V.

Answer 2

You can use the pam_xauth authentication module to forward X11 session cookies across su invocations, without opening up your X server to those users more generally.

This also allows fine-grained control over which users can forward credentials to which other users, via config files in their $HOME/.xauth/ directories.