[user-accounts]: segfault in um_user_set_icon_file()

Bug #908140 reported by matthias langner on 2011-12-23
56
This bug affects 7 people
Affects Status Importance Assigned to Milestone
accountsservice
Fix Released
Critical
gnome-control-center
Fix Released
Critical
gnome-control-center (Ubuntu)
High
Michael Terry
Precise
High
Michael Terry

Bug Description

User account was not possible when i gave in the Icon then gnome closed
I had installed ubuntu in german language but it always changes after restart

ProblemType: Crash
DistroRelease: Ubuntu 11.10
Package: gnome-control-center 1:3.2.0-0ubuntu6
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic i686
ApportVersion: 1.23-0ubuntu3
Architecture: i386
CasperVersion: 1.287
CrashCounter: 1
Date: Fri Dec 23 14:31:44 2011
ExecutablePath: /usr/bin/gnome-control-center
LiveMediaBuild: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
ProcCmdline: gnome-control-center --overview
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SegvAnalysis:
 Segfault happened at: 0x17e2103d: mov 0x10(%eax),%eax
 PC (0x17e2103d) ok
 source "0x10(%eax)" (0x00000010) not located in a known VMA region (needed readable region)!
 destination "%eax" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: gnome-control-center
StacktraceTop:
 ?? () from /usr/lib/control-center-1/panels/libuser-accounts.so
 ?? () from /usr/lib/control-center-1/panels/libuser-accounts.so
 g_cclosure_marshal_VOID__VOID () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
Title: gnome-control-center crashed with SIGSEGV in g_cclosure_marshal_VOID__VOID()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
usr_lib_gnome-control-center:
 deja-dup 20.0-0ubuntu3
 gnome-bluetooth 3.2.0-0ubuntu1
 indicator-datetime 0.3.0-0ubuntu3

StacktraceTop:
 um_user_set_icon_file (user=0x0, icon_file=0x0) at um-user.c:868
 none_icon_selected (menuitem=0x2229fa00, um=0x22278af0) at um-photo-dialog.c:249
 g_cclosure_marshal_VOID__VOID (closure=0x22290f80, return_value=0x0, n_param_values=1, param_values=0x223a59c0, invocation_hint=0xbfebbd60, marshal_data=0x0) at /build/buildd/glib2.0-2.30.0/./gobject/gmarshal.c:85
 g_closure_invoke (closure=0x22290f80, return_value=0x0, n_param_values=1, param_values=0x223a59c0, invocation_hint=0xbfebbd60) at /build/buildd/glib2.0-2.30.0/./gobject/gclosure.c:774
 signal_emit_unlocked_R (node=0x21f62780, detail=0, instance=0x2229fa00, emission_return=0x0, instance_and_params=0x223a59c0) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3272

Changed in gnome-control-center (Ubuntu):
importance: Undecided → Medium
summary: - gnome-control-center crashed with SIGSEGV in
- g_cclosure_marshal_VOID__VOID()
+ gnome-control-center crashed with SIGSEGV in um_user_set_icon_file()
tags: removed: need-i386-retrace

Apparently, this (new?) login component has completely changed the (unwritten?) agreements about what users should be filtered out of the user list in the login dialog.

Traditionally, when presenting a list of users to choose from when logging in, a user whose login shell is specified as /bin/nologin will not be included in the list.

Having a filter list as an extra method is okay (see bug 41908), but it's not the traditional method, and silently changing the behavior is a potential security risk.

If, in keeping with the (in my opinion, ill-advised) shift to capabilities, it is deemed desirable to go with a configurable lower limit on numeric user ids and a filter list, there should at least be some serious public discussion (as, on distro user lists) before the change is implemented, and there should be an incubation period during which both the filter list and the nologin shell are recognized.

I personally would prefer the traditional behavior be kept. There is no reason, on desktops or servers, for /bin/nologin users to be offered the opportunity to log in, in most cases. For those that prefer a separate filter list, the configuration file could be allowed to override the traditional behavior on a per-user basis, whether to show or hide. (Reference bug 41908.)

If the change was made to accommodate wireless carriers who might be deluded about the ability to "keep the platform more secure" by preventing all non-graphical logins, it would be better to add a /bin/guiloginonly default shell value.

Filtering on lack of specified password is a good option, but is also contrary to traditional administration techniques. If such behavior is to be included, it should be set or unset in the configuration files, as well.

visibility: private → public

Looks like the code to do nologin filtering got lost when moving things from gdm to the accountsservice. We should bring it back.

Thank you for your bug report, the issue seems similar to https://bugzilla.gnome.org/show_bug.cgi?id=665066

What uid do you use?

summary: - gnome-control-center crashed with SIGSEGV in um_user_set_icon_file()
+ [user-accounts]: gnome-control-center crashed with SIGSEGV in
+ um_user_set_icon_file()
Changed in gnome-control-center (Ubuntu):
importance: Medium → Low
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-control-center (Ubuntu):
status: New → Confirmed
summary: - [user-accounts]: gnome-control-center crashed with SIGSEGV in
- um_user_set_icon_file()
+ [user-accounts]: segfault in um_user_set_icon_file()
Changed in gnome-control-center (Ubuntu):
status: Confirmed → Triaged
importance: Low → High

Created attachment 58111
Don't use hard-coded minimal UID to exclude users

We should instead filter on the login shell used.

Created attachment 58113
Filter users on nologin rather than minimal UID

Requires the patch from:
https://bugs.freedesktop.org/show_bug.cgi?id=47045
but you might be able to merge it in if you're not interested in the transient correctness ;)

Comment on attachment 58111
Don't use hard-coded minimal UID to exclude users

Review of attachment 58111:
-----------------------------------------------------------------

Not sure I agree with this one.
Yes, we should filter on the login shell. But that doesn't mean that we should ignore the minimal uid

Comment on attachment 58111
Don't use hard-coded minimal UID to exclude users

Review of attachment 58111:
-----------------------------------------------------------------

Just looking at my /etc/passwd, there's odd things like sync and halt, which are not /sbin/nologin

(In reply to comment #5)
<snip>
> Not sure I agree with this one.
> Yes, we should filter on the login shell. But that doesn't mean that we should
> ignore the minimal uid

The minimal UID is only useful to create new users, nothing else. In fact it creates problems with perfectly normal administration policies (like adding new users should start from UID 5000, but users local to the machine get 500 and above, for example).

(In reply to comment #6)
> Just looking at my /etc/passwd, there's odd things like sync and halt, which
> are not /sbin/nologin

They're already ignored, see the daemon->priv->exclusions hash_table that has every item in default_excludes[] added.

The same scheme work for GDM in the past.

Changed in gnome-control-center:
importance: Unknown → Critical
tags: added: rls-mgr-p-tracking

Comment on attachment 58111
Don't use hard-coded minimal UID to exclude users

Review of attachment 58111:
-----------------------------------------------------------------

Ok, after rereading the docs for UID_MIN, I agree now.

I've pushed this in now with a few changes to also catch /bin/false and /usr/sbin/nologin.

Michael Terry (mterry) wrote :

Quick update on what this bug is about. I went through the ProcStatus.txt file on this bug and all its duplicates, and they all specify a UID of 999, which is below the default MIN_UID of 1000.

Now, accountsservice will ignore any user below MIN_UID, so you have to actually log in as the user under that MIN_UID to get the crash. But this is difficult using lightdm, because it won't list such users by default. So enable manual login or use a different login manager.

There are some patches upstream to accountsservice to not use MIN_UID like this (apparently MIN_UID is only supposed to be used at account creation time, not as a way to check 'system user' status). See http://cgit.freedesktop.org/accountsservice/log/ (there are ~5 separate patches for this issue).

I haven't tested these patches yet, but presumably they will allow g-c-c to not freak out when trying to talk to accountsservice about the logged in user with a less-than-MIN_UID uid. Will test and report back.

Changed in gnome-control-center (Ubuntu Precise):
assignee: nobody → Michael Terry (mterry)
Michael Terry (mterry) wrote :

(Another side effect of this accountsservice bug is to see [Invalid UTF-8] in the panel instead of a username.)

affects: gnome-control-center (Ubuntu Precise) → accountsservice (Ubuntu Precise)
Changed in accountsservice:
importance: Unknown → Critical
status: Unknown → Fix Released
Michael Terry (mterry) wrote :

OK, it won't be as simple as grabbing those patches. There are two problems here: (1) should we treat users < MIN_UID as system users or not and (2) handling a logged in system user better.

Presumably these reports from 999 users are people that somehow created a <MIN_UID user that they did not think was a system user. So if we fix (1) by fixing how we identify system users (like upstream did by looking at login shells instead), (2) is a lower priority.

But for some reason, many of Ubuntu's system users have reasonable shells like /bin/sh or /bin/bash. So if we simply use the upstream patches, we'll get a whole bunch of system users being misidentified as normal users.

I looked back at pre-3.0 GDM, and we had patched it to respect MIN_UID. So I guess on Ubuntu, MIN_UID is a valid method of determining system users. Which means we don't need to worry about grabbing those upstream patches (and note that when we do, we need to patch it to respect MIN_UID again).

This implies that the users that reported this crash were doing something 'unsupported' by treating a <MIN_UID user as a normal user.

Thus to fix this, we have to properly fix problem (2) and better handle the situation of having a logged in system user. This means having gnome-control-center handle being run under a user that isn't in accountsservice (or, at least not crash).

Michael Terry (mterry) wrote :

Ah, the LiveCD ubuntu user is uid 999. That explains that.

Michael Terry (mterry) on 2012-04-10
affects: accountsservice (Ubuntu Precise) → gnome-control-center (Ubuntu Precise)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-control-center - 1:3.4.0-0ubuntu5

---------------
gnome-control-center (1:3.4.0-0ubuntu5) precise; urgency=low

  [ Jeremy Bicha ]
  * debian/patches/50_ubuntu_systemwide_prefs.patch:
    - Network proxy: Show "apply system wide" for sudo group too
      (LP: #967978, LP: #893842)

  [ Michael Terry ]
  * debian/patches/accounts_handle_system_user.patch:
    - Disable user controls when no user is selected, to prevent crashes
      in code that doesn't expect that situation. LP: #908140
 -- Michael Terry <email address hidden> Mon, 09 Apr 2012 22:13:55 -0400

Changed in gnome-control-center (Ubuntu Precise):
status: Triaged → Fix Released
Changed in gnome-control-center:
status: Unknown → Fix Released
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/908140

tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.