switch users and still use display

[f***@protonmail.com]

i log in to x session as user1 on host1
from within a xterm i want to change to user2 on host1 and run x programs
the current way i do this is ssh ***@host1
does using ssh on the same host use encryption
is there another way to do this
i feel like this has been hashed over here previously
i just can't find the answer

[Greg Wooledge]

Post by f***@protonmail.com
i log in to x session as user1 on host1
from within a xterm i want to change to user2 on host1 and run x programs

I'm assuming you mean "ssh -X", or that you've configured the ssh command
to use this option automatically. This is a perfectly good way to do it.

Post by f***@protonmail.com
does using ssh on the same host use encryption

Yes.

Post by f***@protonmail.com
is there another way to do this

Yes, but the other ways are *far* more complicated, especially when
neither user1 nor user2 is root. The issue is that in order to
authenticate yourself to the X server, you present a token, known as
a "magic cookie". Your magic cookie is stored in a file in your home
directory, which by default only you can read. All of the programs
that you run as yourself can read this file and therefore present
the magic cookie on demand.

If user2 is root, you can set an environment variable so that root reads
your magic cookie file, because root can (typically) read every file on
the system.

However, when user2 is *not* root, it has no way to read your magic
cookie. So you need to arrange for some means of conveying this token
to the second user account. None of them are simple.

You're really better off just continuing to use ssh -X ***@localhost.
It does exactly what you want.

[Max Nikulin]

Post by Greg Wooledge
Yes, but the other ways are *far* more complicated, especially when
neither user1 nor user2 is root. The issue is that in order to
authenticate yourself to the X server, you present a token, known as
a "magic cookie".

in some cases

xhost +si:localuser:greg

may help to give access to the X11 socket to all processes running by
another user.

It may be more tricky to arrange permissions for GPU, audio devices, and
other hardware. By default udev and systemd-logind "uaccess" feature
dynamically grants access to currently active user through ACLs. Adding
another user to a number of groups may give it *permanent* access to
that devices.

The actual question is if applications running by different users should
appear on the same X11 display or switching between user sessions (using
Ctrl+Alt+F*, desktop environment menu, CLI commands) is acceptable or
even desired.

In the case of the same display another user may sniff selection
(clipboard), key press events.

[Richmond]

Post by f***@protonmail.com
i log in to x session as user1 on host1
from within a xterm i want to change to user2 on host1 and run x programs
does using ssh on the same host use encryption
is there another way to do this
i feel like this has been hashed over here previously
i just can't find the answer

You can do it using su, after you have made the following changes:

diff /etc/pam.d/su-l~ /etc/pam.d/su-l
6a7

Post by f***@protonmail.com
session optional pam_xauth.so

I.e. add that session line to the end of the file.

Some people might claim that this is insecure. I don't think it is in a
single user environment.

[f***@protonmail.com]

simple is better
thanks

does ssh destinguish between "ssh host1" and "ssh localhost"

Post by Greg Wooledge

Post by f***@protonmail.com
i log in to x session as user1 on host1
from within a xterm i want to change to user2 on host1 and run x programs

I'm assuming you mean "ssh -X", or that you've configured the ssh command
to use this option automatically. This is a perfectly good way to do it.

Post by f***@protonmail.com
does using ssh on the same host use encryption

Yes.

Post by f***@protonmail.com
is there another way to do this

Yes, but the other ways are *far* more complicated, especially when
neither user1 nor user2 is root. The issue is that in order to
authenticate yourself to the X server, you present a token, known as
a "magic cookie". Your magic cookie is stored in a file in your home
directory, which by default only you can read. All of the programs
that you run as yourself can read this file and therefore present
the magic cookie on demand.
If user2 is root, you can set an environment variable so that root reads
your magic cookie file, because root can (typically) read every file on
the system.
However, when user2 is *not* root, it has no way to read your magic
cookie. So you need to arrange for some means of conveying this token
to the second user account. None of them are simple.
It does exactly what you want.

[Greg Wooledge]

Post by f***@protonmail.com
simple is better
thanks
does ssh destinguish between "ssh host1" and "ssh localhost"

Depends on how everything is configured. It can.

If you prefer 'ssh -X ***@host1' and if that works for you, then you
can use that.

You're over-thinking this, I suspect.

[e***@gmx.us]

Post by f***@protonmail.com
does ssh destinguish between "ssh host1" and "ssh localhost"

Probably the interface it uses. host1 -> eth0 and localhost -> lo. Unless
you've done something funny with hostnames or routing.

Anyhow that's my guess, and if not, someone will be along in a minute to
educate us both.

--
Nahh, that impending sound of doom is just the blades on my leatherman locking.

-- Majdi on ASR

[Hans]

Some window managers are offering an option, to change the user (plasma = KDE
does it, for example.). It is also possible, to start a new X-session and
login with another user. Doing so, you have 2 X-session open.

The option is also, to change the user, or, add another user with a new
session.

Sometimes, I need to start an application as root in X (for example, if I want
to edit a configuration file, only rott is allowed to edit) ands I want to use
a graphical writer, like kwrite (just an example).

Instead of logging out and relogon into the window manager as root, I am
starting a shell., and enter "su -p" (this meany, preserve my environment).
Thus I can start any graphical application from the shell (starting kwrite
with the command) and it will start with root permissions.

In earlier times, there was "sux" a wrapper for su, but this is no more
available.

I never found an official documentation about "su -p", just found it myself,
but I read, "su -" shall do the same. It does not.

Maybe your question aimed to this scenario, if so, there is my solution.

Have fun!

Best

Hans

[David Wright]

Post by Hans
I never found an official documentation about "su -p", just found it myself,
but I read, "su -" shall do the same. It does not.

When you write something like this, can you accompany it with a
reference? The essential package util-linux's man page seems to
contradict whatever it was you found and read:

-, -l, --login
Start the shell as a login shell with an environment
similar to a real login:

[ … four bullet points … ]

-m, -p, --preserve-environment
Preserve the entire environment, i.e., do not set HOME,
SHELL, USER or LOGNAME. This option is ignored if the
option --login is specified.

Cheers,
David.

[Florent Rougon]

Hi,

Le 27/07/2024, David Wright <de

Post by David Wright

Post by Hans
I never found an official documentation about "su -p", just found it myself,
but I read, "su -" shall do the same. It does not.

When you write something like this, can you accompany it with a
reference? The essential package util-linux's man page seems to

AFAIUI, Hans essentially meant that 'su -p' allows him to start
graphical programs as root inside an X session running as another user,
and that 'su -' doesn't “do the same” (i.e., it doesn't allow starting
graphical programs as root inside an X session running as another user).
Which I am inclined to believe, although I'm reluctant to try 'su -p'
for fear of creating a mess in my normal user setup:

~ % su -p
Password:
zsh compinit: insecure directories and files, run compaudit for list.
Ignore insecure directories and files and continue [y] or abort compinit [n]? ^C

Regards

[Greg Wooledge]

Post by Florent Rougon
Which I am inclined to believe, although I'm reluctant to try 'su -p'
~ % su -p
zsh compinit: insecure directories and files, run compaudit for list.
Ignore insecure directories and files and continue [y] or abort compinit [n]? ^C

I don't use zsh, so I don't quite understand what "compinit" means.
But, just looking at the su(1) man page:

-m, -p, --preserve-environment
Preserve the entire environment, i.e., do not set HOME, SHELL, USER
or LOGNAME. This option is ignored if the option --login is
specified.

The main issue here is likely to be the HOME variable. If you're running
a shell as root, but with HOME=/home/florent or whatever, then some of
the programs you start may create new dot files inside /home/florent/.
These files will be owned by root (because the programs are running as
root). Then, at some point in the future, if you run those same programs
as florent, you won't be able to change the contents of the dot files.
(You would, however, be able to remove them.)

That's not a security hole or anything like that, but it might cause some
surprises.

A secondary issue might be the mismatch between the effective UID (0)
of the programs you run, and the LOGNAME/USER variables (florent). Some
programs may act upon one, and some may act upon the other. Some may
even create a strange mixture of both. I don't have any specific examples
of this.

Realistically, what one *wants* from su is for it to override the HOME,
PATH, USER and LOGNAME variables. The version of su in Debian prior to
buster used to do that, and everything was peachy. The version of su in
buster and beyond no longer sets PATH by default. However, you can fix
that! All you have to do is create a one-line configuration file:

hobbit:~$ cat /etc/default/su
ALWAYS_SET_PATH yes

Then the buster+ version of su will behave sensibly, changing the PATH
variable to a standard one which includes /usr/sbin and so on when you
become root.

[Florent Rougon]

Hi,

Post by Greg Wooledge
I don't use zsh, so I don't quite understand what "compinit" means.

It is a Zsh function that initializes completion for the current
session. From zshall(1):

Use of compinit

(...)

To initialize the system, the function compinit (...) should be
autoloaded (...), and then run simply as `compinit'. This will define
a few utility functions, arrange for all the necessary shell functions
to be autoloaded, and will then re-define all widgets that do
completion to use the new system.

Post by Greg Wooledge
-m, -p, --preserve-environment
Preserve the entire environment, i.e., do not set HOME, SHELL, USER
or LOGNAME. This option is ignored if the option --login is
specified.
The main issue here is likely to be the HOME variable. If you're running
a shell as root, but with HOME=/home/florent or whatever, then some of
the programs you start may create new dot files inside /home/florent/.
These files will be owned by root (because the programs are running as
root). Then, at some point in the future, if you run those same programs
as florent, you won't be able to change the contents of the dot files.
(You would, however, be able to remove them.) (...)

Exactly. I was willing to quickly try 'su -p' for the sake of this
thread, but not for more than that.

[ In the past, I used to just 'su' in order to work as root. This worked
fine for a long time, until I had some problems that boiled down to an
administrative task (namely, upgrading an emacs package using apt)
messing with the home directory of the user invoking 'su'—maybe
because of LOGNAME which, after a simple 'su', contains the normal
username, not “root”. Since then, I use 'su -' and the problem didn't
occur anymore (this doesn't allow one to start graphical apps without
already mentioned contortions; for this case, there is 'ssh -X'). ]

Thanks for your other (snipped) comments.

Regards

[Jeffrey Walton]

Post by Greg Wooledge

Post by Florent Rougon
Which I am inclined to believe, although I'm reluctant to try 'su -p'
~ % su -p
zsh compinit: insecure directories and files, run compaudit for list.
Ignore insecure directories and files and continue [y] or abort compinit [n]? ^C

I don't use zsh, so I don't quite understand what "compinit" means.
-m, -p, --preserve-environment
Preserve the entire environment, i.e., do not set HOME, SHELL, USER
or LOGNAME. This option is ignored if the option --login is
specified.
The main issue here is likely to be the HOME variable. If you're running
a shell as root, but with HOME=/home/florent or whatever, then some of
the programs you start may create new dot files inside /home/florent/.
These files will be owned by root (because the programs are running as
root). Then, at some point in the future, if you run those same programs
as florent, you won't be able to change the contents of the dot files.
(You would, however, be able to remove them.)
That's not a security hole or anything like that, but it might cause some
surprises.

emacs is notorious for that. In fact, if you install a new system, and
`sudo emacs <some config file>`, then emacs will create its own config
directory (.emacs/) in your home directory owned by root. I quickly
learned to run emacs as myself before making adjustments to config
files on a fresh install.

Post by Greg Wooledge
A secondary issue might be the mismatch between the effective UID (0)
of the programs you run, and the LOGNAME/USER variables (florent). Some
programs may act upon one, and some may act upon the other. Some may
even create a strange mixture of both. I don't have any specific examples
of this.

See Chen, Wagner and Dean's Setuid Demystified,
<https://www.usenix.org/legacy/events/sec02/full_papers/chen/chen.pdf>.

Post by Greg Wooledge
Realistically, what one *wants* from su is for it to override the HOME,
PATH, USER and LOGNAME variables. The version of su in Debian prior to
buster used to do that, and everything was peachy. The version of su in
buster and beyond no longer sets PATH by default. However, you can fix
hobbit:~$ cat /etc/default/su
ALWAYS_SET_PATH yes
Then the buster+ version of su will behave sensibly, changing the PATH
variable to a standard one which includes /usr/sbin and so on when you
become root.

Jeff

[Florent Rougon]

Hi,

Post by Jeffrey Walton
emacs is notorious for that. In fact, if you install a new system, and
`sudo emacs <some config file>`, then emacs will create its own config
directory (.emacs/) in your home directory owned by root. I quickly

FTR, the Emacs user configuration directory is ~/.emacs.d (note the “.d”
suffix). ~/.emacs is the traditional user configuration file (other
files that have the same role are ~/.emacs.el, ~/.emacs.d/init.el and
~/.config/emacs/init.el):

https://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html

Regards

[Max Nikulin]

Post by Jeffrey Walton

Post by Greg Wooledge

Post by Florent Rougon
Which I am inclined to believe, although I'm reluctant to try 'su -p'
~ % su -p

[...]

Post by Jeffrey Walton

Post by Greg Wooledge
The main issue here is likely to be the HOME variable. If you're running
a shell as root, but with HOME=/home/florent or whatever, then some of
the programs you start may create new dot files inside /home/florent/.
These files will be owned by root (because the programs are running as
root). Then, at some point in the future, if you run those same programs
as florent, you won't be able to change the contents of the dot files.

[...]

Post by Jeffrey Walton
emacs is notorious for that. In fact, if you install a new system, and
`sudo emacs <some config file>`, then emacs will create its own config
directory (.emacs/) in your home directory owned by root.

I expect that emacs way to edit system files is TRAMP, something like
/sudo:...

In the past I spent some time trying to figure out why bash history did
not work. ~/.bash_history owner was root. I prefer "sudo -i" or "su -"
since that accident. Sometimes I add --whitelist-environment for
specific variables.

[Richmond]

Post by f***@protonmail.com
i log in to x session as user1 on host1
from within a xterm i want to change to user2 on host1 and run x programs
does using ssh on the same host use encryption
is there another way to do this
i feel like this has been hashed over here previously
i just can't find the answer

You can use:

su - user

then run your X program, provided you change:

/etc/pam.d/su-l

and add

session         optional        pam_xauth.so

Some people might say that this is insecure. I don't think it is in a
single user environment.

(I posted this before but I am not sure it got through).