Bug 1086189

Created attachment 884878 [details]
File: backtrace

Created attachment 884879 [details]
File: cgroup

Created attachment 884880 [details]
File: core_backtrace

Created attachment 884881 [details]
File: dso_list

Created attachment 884882 [details]
File: environ

Created attachment 884883 [details]
File: limits

Created attachment 884884 [details]
File: maps

Created attachment 884885 [details]
File: open_fds

Created attachment 884886 [details]
File: proc_pid_status

Created attachment 884887 [details]
File: var_log_messages

Created attachment 884888 [details]
File: sosreport.tar.xz

I'm currently trying to find the pattern that reproduces this.

ugh this sounds bad:

        msg_alloc = 0x7f41623c6cb0 "Creating pipes for GWakeup: Too many open files\n"

a resource leak? This could be a resource leak in the gdm process or another processs.  After using the system for a while, can you run lsof as root?

Michal figured out a reproducer for this on IRC. it's related to bug 1057179:

1) ssh to machine as root
2) su -l to a non-root user
3) run vncpasswd to set a vnc password
4) run vncserver to start vnc
5) connect to the vncserver with a vncviewer from another machine
6) lock the screen
7) note the fail loop, each time it fails it leaks a file descriptor and leaks quickly
8) eventually it crashes GDM.

devack+

So there are two closely related problems:

1) we're only allowing root (the owner of the audit session) to reauthenticate, not the the non-root user who actually is running the session.

2) our error handling for failure in the scenario is inadequate. The code is here:

static gboolean•
allow_user_function (GDBusAuthObserver *observer,•
                     GIOStream         *stream,•
                     GCredentials      *credentials,•
                     GdmSession        *self)•
{•
        uid_t client_uid;•
•
        client_uid = g_credentials_get_unix_user (credentials, NULL);•
        if (client_uid == self->priv->allowed_user) {•
                return TRUE;•
        }•
•
        g_debug ("GdmSession: User not allowed");•
•
        return FALSE;•
}•

We don't emit any sort of signal to the calling code on the error, so the caller can clean up the now defunct session object.  Fix should be straightforward, and will address bug 1057179 at the same time, but I don't know if we're too late in the game to get this in for GA

Created attachment 884973 [details]
Fix resource leak when reauthentication client is rejected

Resolves: #1086189

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0551.html