Bug 133479 - system-config-users traceback when adding new user
system-config-users traceback when adding new user
Product: Fedora
Classification: Fedora
Component: libuser (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
: 133663 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-09-24 07:09 EDT by Dave Cook
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: 0.51.12-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-24 12:41:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test program demonstrating the problem (176 bytes, text/plain)
2004-09-24 09:17 EDT, Nils Philippsen
no flags Details
2nd Test program demonstrating the problem (216 bytes, text/plain)
2004-09-24 09:21 EDT, Nils Philippsen
no flags Details

  None (edit)
Description Dave Cook 2004-09-24 07:09:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3)
Gecko/20040914 Firefox/0.10

Description of problem:
Traceback (most recent call last):
  File "/usr/share/system-config-users/userWindow.py", line 335, in
    if self.parent.ADMIN.lookupGroupById (userEnt.get
(libuser.GIDNUMBER)[0]) != None:
TypeError: argument 2 must be list, not str

This shows up as a hang when not run from a terminal.  You might
consider displaying pygtk tracebacks in a dialog:


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

How reproducible:

Steps to Reproduce:
1. Run system-config-users
2. Enter a user like "bob" and password like "deniro"
3. Click OK

Actual Results:  Traceback and hang

Expected Results:  New user and directory is created.

Additional info:
Comment 1 Nils Philippsen 2004-09-24 09:13:28 EDT
It seems that the traceback stems from the libuser python module
messing with python internals. We could track the problem to these two
lines, it seems to be some weird side-effect in the libuser module:

userWindow.py:243:        userEnt.set(libuser.SHADOWMIN, '0')
userWindow.py:244:        userEnt.set(libuser.SHADOWMAX, '99999')

If these lines are commented out (not a viable workaround) the user
gets added OK.

I'll change the component to libuser and attach a test program.
Comment 2 Nils Philippsen 2004-09-24 09:17:52 EDT
Created attachment 104262 [details]
Test program demonstrating the problem

This test program demonstrates that libuser somehow messes up python internals
when using the set() method on a libuser Entity object on (at least) the
Comment 3 Nils Philippsen 2004-09-24 09:18:43 EDT
NB: You need to run this as root, otherwise you can't get the libuser
admin context.
Comment 4 Nils Philippsen 2004-09-24 09:21:54 EDT
Created attachment 104263 [details]
2nd Test program demonstrating the problem

Another one with code that a bit more resembles what s-c-users is trying to do.
Comment 5 Miloslav Trmač 2004-09-24 12:41:24 EDT
Fixed in libuser-0.51.12-1, which should soon be in rawhide.
Nils, thanks for the excellent test cases.
Comment 6 Nils Philippsen 2004-09-24 13:03:43 EDT
Miloslav, thanks for the excellent reaction! Depending on how things
evolve I might bring s-c-users updates for FC2, would you mind if I
backport the fix and bring an update for libuser?
Comment 7 Miloslav Trmač 2004-09-24 19:24:58 EDT
Just FYI, it is possible to work-around the bug:
        e.set(libuser.FIELD, VALUE)
should be possible to safely replace by
        e.set(libuser.FIELD, [VALUE])
or by
        e[libuser.FIELD] = VALUE

But there were other bug fixes to the Python front-end
(one of which has probably uncovered this bug that was
always there), so using the latest libuser is probably

An update for FC2 is fine with me; if you want me to
do it, just ask.
Comment 8 Nils Philippsen 2004-09-25 06:38:34 EDT
This doesn't work, I already tried out various workarounds before
tracking the problem to be in libuser. If I do what you propose, I get
a valid exception telling me that the method wants an int as its
argument and not a list ;-).

Would you see a problem in just repackaging 0.51.12 for FC2, i.e. do
you have binary compat concerns? I think backporting would work, but
formulating the requirement on a working libuser for s-c-users is
hardly possible, i.e. I can't codify "libuser version x, where
0.51.7-7.1.1 < x < 0.51.8 or x >= 0.51.12" in RPM (the first would
describe a package with backported fix, the second would be the fixed

What do you think?
Comment 9 Miloslav Trmač 2004-09-25 07:54:45 EDT
I have tried those and they worked, although with 0.51.11, not
the FC2 version.

I agree building 0.51.12-0.FC2 is the right solution.
Comment 10 Nils Philippsen 2004-09-26 06:19:53 EDT
*** Bug 133663 has been marked as a duplicate of this bug. ***

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