On 9 Dec 2023 04:37:09 GMT Robert Riches wrote:

> On 2023-12-08, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
> wrote:
>> Hello everyone,
>>
>> I'm just trying to switch the current user and then invoke some X11
>> application, but this does not work.
>>
>> On Redhat-based machines this never was a problem and I need this means
>> to keep my axxounts separate from each other for security reasons.
>> E.g., I do a
>>
>> 'su - bank'
>> and after loggin in I can invoke 'chromium-browser
>> https://pathtoonlinebanking'
>>
>> Now I see, that Debian-based Raspbian OS and Ubuntu (23.10) behave very
>> similar, it looks like this:
>>
>> $ su - test1 Passwort:
>>
>> $ firefox Error: no DISPLAY environment variable specified
>>
>> $ DISPLAY=':0.0' firefox Authorization required, but no authorization
>> protocol specified
>>
>> On Raspbian and on Ubuntu the same lets me assume that it was not me to
>> misconfigure something.
>>
>> Can this be fixed easily? - Thanks!
>>
>> Best regards,
>>
>> Markus
>
> 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.

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

On 09/12/2023 11:54, Markus Robert Kessler wrote:
> 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 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.
--
There is nothing a fleet of dispatchable nuclear power plants cannot do
that cannot be done worse and more expensively and with higher carbon
emissions and more adverse environmental impact by adding intermittent
renewable energy.

On Sat, 9 Dec 2023 11:54:38 -0000 (UTC)
Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:

> What I found out is, that when switching 'su - newaccount', then
>
> - a file ~/.xauth* (e.g.: .xauthOa9EpX) is automatically created
> (by su? by pam?)

Probably with this:

https://www.man7.org/linux/man-pages/man8/pam_xauth.8.html

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On Sat, 9 Dec 2023 12:09:35 +0000 The Natural Philosopher wrote:

> On 09/12/2023 11:54, Markus Robert Kessler wrote:
>> 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 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.

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

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

On Sat, 9 Dec 2023 11:54:38 -0000 (UTC) Markus Robert Kessler wrote:

> On 9 Dec 2023 04:37:09 GMT Robert Riches wrote:
>
>> On 2023-12-08, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
>> wrote:
>>> Hello everyone,
>>>
>>> I'm just trying to switch the current user and then invoke some X11
>>> application, but this does not work.
>>>
>>> On Redhat-based machines this never was a problem and I need this
>>> means to keep my axxounts separate from each other for security
>>> reasons. E.g., I do a
>>>
>>> 'su - bank'
>>> and after loggin in I can invoke 'chromium-browser
>>> https://pathtoonlinebanking'
>>>
>>> Now I see, that Debian-based Raspbian OS and Ubuntu (23.10) behave
>>> very similar, it looks like this:
>>>
>>> $ su - test1 Passwort:
>>>
>>> $ firefox Error: no DISPLAY environment variable specified
>>>
>>> $ DISPLAY=':0.0' firefox Authorization required, but no authorization
>>> protocol specified
>>>
>>> On Raspbian and on Ubuntu the same lets me assume that it was not me
>>> to misconfigure something.
>>>
>>> Can this be fixed easily? - Thanks!
>>>
>>> Best regards,
>>>
>>> Markus
>>
>> 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.
>
> 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

--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

On 12/9/23 15:25, Markus Robert Kessler wrote:
> Hi everyone,

Hi,

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

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.

> I found out, that adding this line
>
> session optional pam_xauth.so
>
> to the front of /etc/pam.d/su

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.

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

Nice work.

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

:-D

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

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.

--
Grant. . . .