Related bug:
mainWindow.populate_group_list() assigns to cn and gid only
if groupEnt.get(libuser.GIDNUMBER) != [], but references the values
unconditionally.

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().

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?

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.

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?

Not directly, you can only check for presence of shadow-only attributes, e.g.
SHADOWNAME or ADMINISTRATORNAME.

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.

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 ?

Thanks.