Red Hat Bugzilla – Bug 133479
system-config-users traceback when adding new user
Last modified: 2007-11-30 17:10:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3)
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)) != 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):
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.
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.
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
SHADOWMIN or SHADOWMAX attributes.
NB: You need to run this as root, otherwise you can't get the libuser
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.
Fixed in libuser-0.51.12-1, which should soon be in rawhide.
Nils, thanks for the excellent test cases.
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?
Just FYI, it is possible to work-around the bug:
should be possible to safely replace 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.
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?
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.
*** Bug 133663 has been marked as a duplicate of this bug. ***