Bug 1328947 - [gnome-terminal] /proc/self/loginuid contains 0xffffffffh
Summary: [gnome-terminal] /proc/self/loginuid contains 0xffffffffh
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 24
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-20 17:01 UTC by Joachim Frieben
Modified: 2017-07-27 13:54 UTC (History)
22 users (show)

Fixed In Version: systemd-229-9.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-23 18:49:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Screenshot of crash location in strcpy-ssse3.S (31.20 KB, image/png)
2016-04-20 17:01 UTC, Joachim Frieben
no flags Details
Fortran sample program pgdemo1.f (30.49 KB, text/plain)
2016-04-20 17:02 UTC, Joachim Frieben
no flags Details
Loginuid patch as suggested in comment 30 (240 bytes, patch)
2016-04-27 04:32 UTC, Joachim Frieben
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1474899 0 unspecified CLOSED GDM user logins failing because of systemd1 service failing 2021-02-22 00:41:40 UTC
Sourceware 19978 0 P2 RESOLVED [glibc] getlogin() returns user name 'NULL' 2020-04-08 15:15:57 UTC

Internal Links: 1474899

Description Joachim Frieben 2016-04-20 17:01:06 UTC
Created attachment 1149143 [details]
Screenshot of crash location in strcpy-ssse3.S

Description of problem:
Running a sample Fortran program pgdemo1.f compiled against libpgplot provided by giza-0.9.4 available at https://sourceforge.net/projects/giza/files/ crashes with a segmentation fault in strcpy-ssse3.S, see attached screenshot.

Version-Release number of selected component (if applicable):
glibc-2.23.1-5.fc24

How reproducible:
Always

Steps to Reproduce:
1. Build giza-0.9.4.
2. Compile pgdemo1.f linking against libpgplot.
3. Run pgdemo1.

Actual results:
Execution of pgdemo1 aborts in strcpy-ssse3.S.

Expected results:
Execution of pgdemo1 completes successfully.

Additional info:
Building giza-0.9.4 and pgdemo1 under Fedora 23, no such crash is observed.

Comment 1 Joachim Frieben 2016-04-20 17:02:03 UTC
Created attachment 1149144 [details]
Fortran sample program pgdemo1.f

Comment 2 Joachim Frieben 2016-04-20 19:16:46 UTC
Using the sample code from https://bugzilla.redhat.com/show_bug.cgi?id=621959#c0, namely

----
#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv)
{
    char *username = getlogin();

    printf("[%s]\n", username);
    return 0;
}
----

it turns out that the getlogin() call in the current glibc erroneously returns the user name 'NULL' whereas in Fedora 23 it returns the correct user name. This wrong value causes the crash whereas execution completes successfully on Fedora 23.

Comment 3 Florian Weimer 2016-04-21 14:38:03 UTC
I cannot reproduce this.  Can you provide more information about your system setup?

In any case, getlogin is allowed to return NULL, and callers have to check for failures.

Comment 4 Joachim Frieben 2016-04-21 17:54:12 UTC
(In reply to Florian Weimer from comment #3)
Fully updated standard network install of Fedora 24 Workstation carried out on 2016-04-20. The failure occurs both on a ThinkPad T400 and on the same system in virtual machines (GNOME Boxes) running Fedora 24 and Ubuntu 16.04 LTS, respectively.

Compile the code snippet from comment 2 with 'cc -o test test.c'; then under Fedora 24 or Ubuntu 16.04 LTS obtain

$ ./test
[(null)]

The same procedure under Fedora 23 results in

$ ./test
[frieben]

Comment 5 Florian Weimer 2016-04-23 14:36:32 UTC
(In reply to Joachim Frieben from comment #4)
> (In reply to Florian Weimer from comment #3)
> Fully updated standard network install of Fedora 24 Workstation carried out
> on 2016-04-20. The failure occurs both on a ThinkPad T400 and on the same
> system in virtual machines (GNOME Boxes) running Fedora 24 and Ubuntu 16.04
> LTS, respectively.

The key point is that this happens for graphical logins with gnome-terminal (xterm is fine).  It seems that gnome-terminal longer creates an utmp entry, so getlogin cannot figure out the login session for the controlling terminal.  Reassigning to gnome-terminal for further investigation.

Comment 6 Christian Persch 2016-04-23 15:29:36 UTC
This is expected; gnome-terminal/vte no longer logs to [uw]tmp since vte 0.42.

Comment 7 Florian Weimer 2016-04-23 15:37:32 UTC
It turns out there is another problem:

[fweimer@localhost ~]$ cat /proc/self/loginuid 
4294967295[fweimer@localhost ~]$ 

This is the root cause for getlogin returning NULL (I forgot that getlogin no longer looks at utmp).

Comment 8 Joachim Frieben 2016-04-23 16:28:35 UTC
(In reply to Florian Weimer from comment #5)
Thanks, on Fedora 23, /proc/self/loginuid indeed contains 1000, on Fedora 24 and 25, /proc/self/loginuid contains 4294967295 when queried from inside an instance of gnome-terminal.
When the 'test*' executable is run inside an xterm, execution completes successfully regardless of the value of /proc/self/loginuid.

Comment 9 Joachim Frieben 2016-04-23 17:29:09 UTC
Fedora 23 and Ubuntu 16.04 LTS are using the same versions of GNOME Terminal (3.18.3) and of vte291 (0.42.5) but in the former case /proc/self/loginuid equals 1000 (first user) but in the latter it equals 4294967295.
Moreover, in Ubuntu 16.04 LTS, cat /proc/self/loginuid executed inside some xterm returns 4294967295, too, but the execution of 'test*' returns the user name as expected.

Comment 10 Florian Weimer 2016-04-23 17:52:05 UTC
FWIW, I think the incorrect value for /proc/self/loginuid should be a Fedora 24 release blocker because I expect that the impact extends far beyond fish.

Comment 11 Joachim Frieben 2016-04-23 17:59:58 UTC
Btw, (4294967295)10 = (FFFFFFFF)16.

Comment 12 Egmont Koblinger 2016-04-23 18:15:33 UTC
[uw]tmp's removal was discussed at https://bugzilla.gnome.org/show_bug.cgi?id=747046.

I have no clue what /proc/self/loginuid is (yeah I could google it, but I just don't care that much at this point). The only thing that's sure is that it has nothing with utmp. utmp is clearly a user-space stuff writing records into a certain file, sure there's absolutely no way the kernel would go ahead and interpret that file and expose it under /proc.

So in this bugreport we're talking about two totally independent things.

(In the mean time I confirm that in Ubuntu 16.04 both under g-t and xterm /proc/self/loginuid contains 4294967295.)

Comment 13 Florian Weimer 2016-04-23 18:39:54 UTC
(In reply to Egmont Koblinger from comment #12)
> [uw]tmp's removal was discussed at
> https://bugzilla.gnome.org/show_bug.cgi?id=747046.
> 
> I have no clue what /proc/self/loginuid is (yeah I could google it, but I
> just don't care that much at this point). The only thing that's sure is that
> it has nothing with utmp. utmp is clearly a user-space stuff writing records
> into a certain file, sure there's absolutely no way the kernel would go
> ahead and interpret that file and expose it under /proc.
> 
> So in this bugreport we're talking about two totally independent things.

The relationship between the two is that utmp is used as a fallback mechanism if /proc/self/loginuid is not available or unusable for some reason.  xterm adds the utmp entry and thus papers over the (more severe) bug that /proc/self/loginuid is 2**32 - 1.

I don't know why the login shell running under gnome-terminal does not receive a proper loginuid.

> (In the mean time I confirm that in Ubuntu 16.04 both under g-t and xterm
> /proc/self/loginuid contains 4294967295.)

That's also what happens with Fedora 24, but xterm enables the utmp workaround.  Comment 7 is incorrect; there is still a fallback for utmp in glibc.

Comment 14 Egmont Koblinger 2016-04-23 19:04:46 UTC
(In reply to Florian Weimer from comment #13)

> I don't know why the login shell running under gnome-terminal does not
> receive a proper loginuid.

I think the value of loginuid should have nothing to do with terminals/shells. E.g. for graphical applications launched via the graphical menu I'd expect to have the same value. It should not be the responsibility of terminal emulators or shells to fix this up.

So it's probably a bug in the graphical login manager (gdm and friends) or the corresponding PAM configuration.

Comment 15 Egmont Koblinger 2016-04-23 19:06:48 UTC
http://stackoverflow.com/a/28857109/4457671 ?

Comment 16 Egmont Koblinger 2016-04-23 20:00:45 UTC
(In reply to Florian Weimer from comment #13)

> The relationship between the two is that utmp is used as a fallback
> mechanism if /proc/self/loginuid is not available or unusable for some
> reason.

@Florian, did you mean this in the context of getlogin()? Do you happen to have some further information? I can't find anything on the net, and this is not how getlogin() works on Ubuntu 16.04, it only looks at utmp. (I don't have access to RH.) Where does this feature come from? Is it perhaps a RH-specific patch to glibc?

Comment 17 Florian Weimer 2016-04-23 20:36:34 UTC
(In reply to Egmont Koblinger from comment #16)
> (In reply to Florian Weimer from comment #13)
> 
> > The relationship between the two is that utmp is used as a fallback
> > mechanism if /proc/self/loginuid is not available or unusable for some
> > reason.
> 
> @Florian, did you mean this in the context of getlogin()? Do you happen to
> have some further information? I can't find anything on the net, and this is
> not how getlogin() works on Ubuntu 16.04, it only looks at utmp.

Really?  glibc should attempt to open /proc/self/loginuid, and running the reproducer under strace shows it.

> (I don't have access to RH.)

I don't think this bug made it into a release of Red Hat Enterprise Linux, I'm pretty sure it would be caught during QE, like it was noticed during Fedora QE.

> Where does this feature come from? Is it perhaps a RH-specific patch to glibc?

No, it's in upstream glibc.  If Ubuntu does not have a /proc/self/loginuid file, its kernel was compiled without CONFIG_AUDITSYSCALL.  In this case, Canonical needs to patch their operating system so that it maintains utmp everywhere (e.g., revert the change alluded to in comment 6), or they will never get a working getlogin function.  This is a completely different bug from what is being discussed here, although its impact is similar.

In contrast, for Fedora, the expectation is that user sessions have a correct and usable value in /proc/self/loginuid, and this bug is about figuring out why it does not happen.  Egmont in comment 14 correctly writes that the culprit probably is not gnome-terminal, but I'm not familiar how the terminal processes are launched and have not traced things further back.

Comment 18 Egmont Koblinger 2016-04-23 20:43:17 UTC
(In reply to Florian Weimer from comment #17)

> Really?  glibc should attempt to open /proc/self/loginuid, and running the
> reproducer under strace shows it.

My bad. I straced "who am i" which apparently doesn't call getlogin(). stracing "logname" does indeed refer to /proc/self/loginuid first, and prints the username corresponding to that value (unless it's 2^32-1 in which case it proceeds to utmp). Thanks!

Comment 19 Steve Grubb 2016-04-24 17:57:44 UTC
That value that you are seeing is -1 represented as a 32 bit unsigned integer. This means that the loginuid was not set by the entry point daemon. Or perhaps the terminal was spawned by the system dbus which as a daemon should have -1 for its loginuid. (The session dbus should have a correct loginuid.)  The loginuid works great for processes that fork such as logging in at the console. The child always inherits the parents loginuid. But on the desktop, dbus activation is used which does not follow the fork model from way back in time. One process with a loginuid requests something of dbus which then forks itself to run the child.

The implication of this is that any command run by the user in a shell started by activation will not be attributed to the correct user in the audit system. That makes for a big security hole, but then again we do not take the desktop through common criteria. On the otherhand, people have complained on the linux-audit mail list that they expected the desktop to be auditable. The only safe way to fix this is to have kdbus and full credential passing inside the kernel.

So, if pstree or ppid shows dbus as the parent, that would explain things.

Comment 20 Egmont Koblinger 2016-04-24 18:44:49 UTC
I can see "/sbin/upstart --user" in pstree as the parent of gnome-terminal, child of lightdm (Ubuntu, Unity), although I sure expected to see "dbus" there.

I don't think any desktop is designed in a way that user apps are launched from a system-wide daemon.

These upstart or dbus daemons are run as the user whoever runs the graphical environment. And as such, the existence of such helper daemons should be the private internal business of desktop systems such as Gnome, not having to do anything with authentication or the loginuid business.

This user-level upstart or dbus daemon should already start up with loginuid being set to the actual user.

Comment 21 Steve Grubb 2016-04-24 19:04:48 UTC
The rules around audit are that anything that runs on behalf of the user should have a loginuid that matches the original user its performing action for. If the upstart user process has the user's id, I wonder if it has a properly set loginuid?

cat /proc/<pidof upstart --user>/loginuid

Knowing this would at least make it an explained condition. We have had to patch things in the past to fix start up order of things to make sure they start after a loginuid has been set.

The gnome desktop mostly worked fine wrt audit in the past. The only known problems were using any gui user account or time setting utilities. Doing the same from the command line in a terminal worked fine because children get the right loginuid.

Comment 22 Egmont Koblinger 2016-04-24 19:20:49 UTC
I get -1 (well, 4294967295, but let's call it -1 for brevity) for the upstart process.

As far as I understand, the two main rules for the loginuid are: 1) it's preserved across fork/exec, 2) you can change -1 into any other value (not necessarily your userid) for any of your own processes, but you cannot further alter a value that's different from -1.

If upstart's loginuid was set to my user id before upstart forks any children, then my entire desktop (including gnome-terminal and its shells) would run with loginuid properly set to my user id.

So, again, I believe the culprit is the graphical login manager or its PAM configuration which should properly initialize this value, but doesn't.

This is the point where the issue needs to be addressed; definitely not where the terminal emulator or the shell within is started up. loginuid's value needs to be correct for non-terminal apps as well.

Comment 23 Joachim Frieben 2016-04-24 19:24:07 UTC
On Fedora 24, 'pstree -Aus <pid>' for process gnome-terminal returns:

systemd---systemd(frieben)---gnome-terminal--+-csh---pstree
                                             |-{dconf worker}
                                             |-{gdbus}
                                             `-{gmain}

Process systemd has loginuid 4294967295.

Comment 24 Joachim Frieben 2016-04-24 19:38:04 UTC
On Fedora 23, 'pstree -Aus <pid>' for process gnome-terminal returns:

systemd---gnome-terminal-(frieben)-+-csh---pstree
                                   |-{dconf worker}
                                   |-{gdbus}
                                   `-{gmain}

Process systemd has loginuid 4294967295.

Comment 25 Steve Grubb 2016-04-24 19:50:33 UTC
I am wondering if the parent process is dying and then init (systemd) becomes the parent. What is really missing from pstree is the ability to show loginuid and sessionid.

Comment 26 Steve Grubb 2016-04-24 20:03:51 UTC
I think this is the critical section and should be similar for other display managers

        |-lightdm-+-Xorg
        |         |-lightdm-+-cinnamon-sessio(sgrubb)-+-abrt-applet-+-{gdbus}
        |         |         |                         |             `-{gmain}
        |         |         |                         |-cinnamon-launch-+-

The second lightdm has my loginuid and sessionid so everything spawned by it or its children have the correct loginuid.

Comment 27 Egmont Koblinger 2016-04-24 20:11:21 UTC
(In reply to Steve Grubb from comment #26)

> The second lightdm has my loginuid and sessionid [...]

I agree, I also think that this is how it _should_ work :)

I can see a similar structure

        ├─lightdm─┬─Xorg───{Xorg}
        │         ├─lightdm─┬─upstart─┬─at-spi-bus-laun─┬─dbus-daemon
        │         │         │         │                 ├─{dconf worker}

but all of these processes have -1 as their loginuid.

This is under Ubuntu, and the technical reason why loginuid is not properly set _might_ be completely different in the two distros.

Comment 28 Matthias Clasen 2016-04-25 15:00:14 UTC
The larger picture here is that we are using systemd --user and a user bus in recent Fedora. The user bus and processes that are activated on it are not scoped to the current login session, they can outlive it and possibly be used by subsequent login sessions of the same user. 

(this email has a longer explanation and some diagrams https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html )

I think a fix for the immediate problem would be to add pam-loginuid to the system-user pam configuration. That should make the systemd --user instance (and the user bus and all that is activated on it) have the right loginuid.

Comment 29 Debarshi Ray 2016-04-25 17:52:57 UTC
The difference between xterm and gnome-terminal is due to the former not being activated over D-Bus, while gnome-terminal (actually gnome-terminal-server) is. I don't have a Fedora 24 system at hand (yet), but I predict that something like terminix will have the same problem as gnome-terminal.

On Fedora 24, the D-Bus user session bus that spawns gnome-terminal-server is setup by systemd --user, which doesn't have a valid loginuid (as explained in comment 28). Fedora 23 uses a D-Bus login session bus that was set up by X/gnome-session and had a valid loginuid, and hence doesn't suffer from this bug.

Comment 30 Zbigniew Jędrzejewski-Szmek 2016-04-25 19:35:34 UTC
I filed an upstream PR: https://github.com/systemd/systemd/pull/3120, let's continue the discussion there.

If this should be fixed before F24 is released, please file for a freeze exception.

Comment 31 Joachim Frieben 2016-04-27 04:32:19 UTC
Created attachment 1151196 [details]
Loginuid patch as suggested in comment 30

The modification suggested in comment 30 resolves this issue. Please trigger a build of package systemd incorporating the attached patch.

Comment 32 Joachim Frieben 2016-05-27 16:32:21 UTC
Issue has been fixed in the Fedora (rawhide) development tree in package systemd-230-1.fc25. Unless Fedora 24 is going to update to this new upstream release, too, an errata build with the patch from attachment 1151196 [details] is still needed.

Comment 33 Joachim Frieben 2016-07-19 21:03:09 UTC
Issue still affects current Fedora 24 including systemd-229-8.fc24.

Comment 34 Steve Grubb 2016-07-20 15:10:28 UTC
Any chance the patch is going to make it into F24? This is interfering with my work.

Comment 35 Fedora Update System 2016-07-21 06:47:33 UTC
systemd-229-9.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-47bda25e7a

Comment 36 Fedora Update System 2016-07-21 18:53:11 UTC
systemd-229-9.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-47bda25e7a

Comment 37 Fedora Update System 2016-07-23 18:48:19 UTC
systemd-229-9.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.