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 user2@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jul 27, 2024 at 15:44:51 +0000, fxkl47BF@protonmail.com wrote:

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 user2@host1

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.

does using ssh on the same host use encryption

Yes.

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 user2@localhost.
It does exactly what you want.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fxkl47BF@protonmail.com writes:

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 user2@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

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jul 27, 2024 at 16:43:50 +0000, fxkl47BF@protonmail.com wrote:

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 user2@host1' and if that works for you, then you
can use that.

You're over-thinking this, I suspect.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/27/24 12:43, fxkl47BF@protonmail.com wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat 27 Jul 2024 at 23:21:06 (+0200), Hans wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Le 27/07/2024, David Wright <de
blis@lionunicorn.co.uk> a écrit:

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:

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

--
Florent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fxkl47BF@protonmail.com wrote:

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 user2@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

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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Le 02/08/2024, Greg Wooledge <greg@wooledge.org> a écrit:

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.

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.) (...)

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

--
Florent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Aug 02, 2024 at 11:35:58 +0200, Florent Rougon wrote:

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Le 02/08/2024, Jeffrey Walton <noloader@gmail.com> a écrit:

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

--
Florent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)