Bug 174716 - system-config-users traceback on commandline startup
system-config-users traceback on commandline startup
Product: Fedora
Classification: Fedora
Component: system-config-users (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
Depends On:
  Show dependency treegraph
Reported: 2005-12-01 12:28 EST by Brian O Smith
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-07 11:57:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brian O Smith 2005-12-01 12:28:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
On starting system-config-users from the command line as root I see the following traceback (see Actual Results).

Also getting hangs when creating/deleting users or changing users' group assignments - e.g. when unselecting a user's original primary group in the User Properties popup (they're now assigned to a different group as their primary) I get:

** (system-config-users.py:13018): CRITICAL **: extract_id: assertion `array != NULL' failed

** (system-config-users.py:13018): CRITICAL **: lu_dispatch: assertion `ldata != LU_VALUE_INVALID_ID' failed

(system-config-users.py:13018): GLib-GObject-CRITICAL **: g_value_array_free: assertion `value_array != NULL' failed
Traceback (most recent call last):
  File "/usr/share/system-config-users/userProperties.py", line 530, in on_ok_button_clicked
  File "/usr/share/system-config-users/mainWindow.py", line 428, in refresh_users_and_groups
    gidNumber = gidNumber[0]
IndexError: list index out of range

But this could be related to the original condition I guess.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.as root:# system-config-users

Actual Results:  ** (system-config-users.py:13018): CRITICAL **: extract_id: assertion `array != NULL' failed

** (system-config-users.py:13018): CRITICAL **: lu_dispatch: assertion `ldata != LU_VALUE_INVALID_ID' failed

(system-config-users.py:13018): GLib-GObject-CRITICAL **: g_value_array_free: assertion `value_array != NULL' failed

Expected Results:  no tracebacks

Additional info:
Comment 1 Miloslav Trmač 2006-03-05 21:47:33 EST
Related bug:
mainWindow.populate_group_list() assigns to cn and gid only
if groupEnt.get(libuser.GIDNUMBER) != [], but references the values

To reproduce: add a group to /etc/gshadow, remove it from /etc/group.
Probably the easiest way to solve this is to display an error message
similar to the one in refresh_users().
Comment 2 Nils Philippsen 2006-06-07 11:34:22 EDT
Hm, the problem is that this line:

members = self.ADMIN.enumerateUsersByGroup(groupName)

only issues a warning, but doesn't throw an exception that I could catch to
notice something went wrong, even members is an empty array, not None, afterwards.

Do you have an idea how I should detect that?
Comment 3 Nils Philippsen 2006-06-07 11:37:39 EDT
BTW: re comment #1, this was an indentation problem which I've fixed in CVS, but
this doesn't change a thing with this issue.
Comment 4 Nils Philippsen 2006-06-14 02:41:44 EDT
DB lost this:

------- Additional Comments From Miroslav Trmac  2006-06-10 16:04 EST -------
The problem is not in enumerateUsersByGroup.  refresh_users_and_groups accesses
GIDNUMBER of a loaded group entity without verifying it exists.

While refresh_users (run during MainWindow.__init__) verifies that
user.GIDNUMBER is present for all loaded users, and s-c-u exits with an error
message if /etc/passwd and /etc/shadow are inconsistent, refresh_groups doesn't
perform such a check.  Groups present in /etc/gshadow but not in /etc/group are
then silently ignored in populate_group_list, and surface only in
refresh_users_and_groups as the stack trace above.

(The only way I know to reproduce the stack trace with recent libuser is to
create an "orphan" group in /etc/gshadow, then create and remove an user
with the same name, which triggers the refresh_users_and_groups call.)

To repeat comment #1, the easiest way to solve this is to check for GIDNUMBER
presence in refresh_group, and exit s-c-u with an error message if an
inconsistency is found.

The FC-4 libuser has bugs in its error handling that cause the warning and
assertion failure messages above, but they are AFAICS not the immediate cause
of this problem.

To which I answered roughly that:
I've checked in changes to CVS that do what you proposed. Now is there a way doe
me to easily find out inconsistencies with libuser where entries are present in
/etc/passwd or /etc/group, but not in their respective shadow files?
Comment 5 Miloslav Trmač 2006-06-16 11:24:33 EDT
Not directly, you can only check for presence of shadow-only attributes, e.g.

OTOH s-c-u seems to work without these attributes, and "shadow or not" is more
complicated on LDAP, where some attributes may be present and some not.
Comment 6 Christian Iseli 2007-01-22 05:21:00 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?


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