sudo apparently sets the wrong requesting user (which is just the real
uid of the process, iirc) when calling the pam stack, which breaks at
least pam_xauth. compare the debug outputs:

=== su (works) ===
pam_unix(su:session): session opened for user root by obuddenh(uid=1002)
pam_xauth(su:session): requesting user 1002/1002, target user 0/0
pam_xauth(su:session): /home/obuddenh/.xauth/export does not exist, ignoring
pam_xauth(su:session): /root/.xauth/import does not exist, ignoring
pam_xauth(su:session): reading keys from `/home/obuddenh/.Xauthority'
pam_xauth(su:session): running "/usr/bin/xauth -f /home/obuddenh/.Xauthority nlist :0" as 1002/0
pam_xauth(su:session): writing key `0100 0007 74726f6c6c3038 0001 30 0012 4d49542d4d414749432d434f4f4b49452d31 0010 8977806e7957465e43f8847d0562c87d ' to temporary file `/root/.xauthyPpqBT'
pam_xauth(su:session): running "/usr/bin/xauth -f /root/.xauthyPpqBT nmerge -" as 0/0

=== sudo (broken) ===
pam_unix(sudo:session): session opened for user root by obuddenh(uid=0)
pam_xauth(sudo:session): requesting user 0/0, target user 0/0
pam_xauth(sudo:session): /root/.xauth/export does not exist, ignoring
pam_xauth(sudo:session): /root/.xauth/import does not exist, ignoring
pam_xauth(sudo:session): reading keys from `/root/.Xauthority'
pam_xauth(sudo:session): running "/usr/bin/xauth -f /root/.Xauthority nlist :0" as 0/1002
pam_xauth(sudo:session): no key

the same bug appears to be reported at:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/370607

Background: sudoers(5) says

    # Run X applications through sudo; HOME is used to find the
    # .Xauthority file.  Note that other programs use HOME to find
    # configuration files and this may lead to privilege escalation!
    Defaults env_keep += "DISPLAY HOME"

This works for root because root can access the original
$HOME/.Xauthority. non-root users, however, cannot.


Using pam_xauth(8) should solve this problem. pam_xauth can conveniently
transfer (and later revoke) an authorization. Adding

    session       optional     pam_xauth.so debug

is sufficient. There's a primitive access control involved, but it's not
relevant to this issue.

The following commands illustrate the problem (they correspond to
Oswald's debug output below). Running

    foo@...$ su -c xterm bar

will cause pam_xauth to transfer a key from foo to bar, after which an
xterm is opened. With sudo, however,

    foo@...$ sudo -u bar xterm

pam_xauth attempts to transfer an xauth key from *root* to bar, which
fails because root of course cannot provide a key only *foo* has.

Christian Kastner wrote:

Also remember the XAUTHORITY variable and that session managers such
as GNOME override the setting of it.  AFAICS the XAUTHORITY variable
overrides the use of HOME to locate that file.

  $ printenv XAUTHORITY
  /home/rwp/.Xauthority

But it might be set /tmp/something or /var/run/something too depending
upon the session manager.  And that it must be possible to read that
file by the other user.  For example if it is stored over NFS then
root by default won't have permission there.

Bob

Christian Kastner wrote:

Also remember the XAUTHORITY variable and that session managers such
as GNOME override the setting of it.  AFAICS the XAUTHORITY variable
overrides the use of HOME to locate that file.

  $ printenv XAUTHORITY
  /home/rwp/.Xauthority

But it might be set /tmp/something or /var/run/something too depending
upon the session manager.  And that it must be possible to read that
file by the other user.  For example if it is stored over NFS then
root by default won't have permission there.

Bob

I started looking through the code but then realized the problem is
irreconcilable design choices between sudo and pam_xauth (I don't know
how I missed this previously):

pam_xauth(8) says:

    pam_xauth will work only if it is used from a setuid application in
    which the getuid() call returns the id of the user running the
    application [...]

and sudo(8) says:

    The real and effective uid and gid are set to match those of the
    target user [...]


So either one would have to change sudo to set the (just the) RUID after
passing through the PAM stack, or pam_xauth to rely on something else
than the RUID.

Incidentally, both sudo and su set PAM_RUSER to the requesting user,
which pam_xauth could use, but there are probably a few security issues
to consider. I'll ask the PAM devel list about that.

tags #687164 moreinfo
thanks

Hi,

is this still reproducible in current unstable?

How would I obtain that debug output?

Greetings
Marc

tags #687164 moreinfo
thanks

Hi,

is this still reproducible in current unstable?

How would I obtain that debug output?

Greetings
Marc

no (logs edited for brevity):

=== su ====
(to root) ossi on pts/13
pam_xauth(su:session): requesting user 1000/100, target user 0/0
pam_xauth(su:session): reading keys from `/home/ossi/.Xauthority'
pam_xauth(su:session): running "/usr/bin/xauth -f /home/ossi/.Xauthority nlist :0" as 1000/100
pam_xauth(su:session): writing key `blabla' to temporary file `/root/.xauthlSdyO1'
pam_xauth(su:session): running "/usr/bin/xauth -f /root/.xauthlSdyO1 nmerge -" as 0/0

=== sudo ===
     ossi : TTY=pts/13 ; PWD=/root ; USER=root ; COMMAND=/bin/bash
pam_unix(sudo:session): session opened for user root(uid=0) by ossi(uid=1000)
pam_xauth(sudo:session): requesting user 1000/100, target user 0/0
pam_xauth(sudo:session): reading keys from `/home/ossi/.Xauthority'
pam_xauth(sudo:session): running "/usr/bin/xauth -f /home/ossi/.Xauthority nlist :0" as 1000/0
pam_xauth(sudo:session): writing key `blabla' to temporary file `/root/.xauthUuD5Vi'
pam_xauth(sudo:session): running "/usr/bin/xauth -f /root/.xauthUuD5Vi nmerge -" as 0/0

note that there is still a difference in the gid used for the 1st xauth
call for some reason, but that doesn't impact function.
add "debug" to the pam_xauth.so line, as is shown in the followup
messages to this report, and as you could have found out yourself by
searching for "linux pam enable debug output". ;-)

p.s.: it seems pointless to include both nnn-submitter@ and the actual
submitter in the 'to' list.

tags #687164 - moreinfo
thanks

You seem to be a really nice guy. The perfect match to spend my weekend
with. I'll take another look at this bug report when I get around to it,
maybe in another five years.

Thanks for being helpful and friendly. You surely made my weekend a
better one.

Control: tags -1 moreinfo help
Control: outlook -1 wait for help, close 2022-04-30
thanks

The Debian system does not contain any pam.d configuration containing
pam_xauth.so. The only reference to that content is, according to
codesearch.debian.net shadow_1:4.11.1+dfsg1-2/etc/pam.d/su, but the
/etc/pam.d/su on my systems don't have any pam_xauth.so line. apt-file
concurs with that, /etc/pam.d/su on Debian comes from util-linux and not
from shadow.

The reporter has not been willing to be helpful in reproducing this bug,
and I don't have time to play hide-and-seek. Unless somebody helps me in
reproducing this bug, this bug report will be closed by the End of April
2022. I deeply regret being too stupid to need more help here.

To and Cc has been severely trimmed down since the original reporter
told me off for receiving two copies of the last communication.

Greetings
Marc

P.S. Ich kann so nicht arbeiten