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 on_userWin_ok_button_clicked 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: http://www.daa.com.au/pipermail/pygtk/attachments/20030828/e36f17bb/gtkexcepthook.py http://www.daa.com.au/pipermail/pygtk/attachments/20030928/755c8f86/gtkexcepthook.bin Version-Release number of selected component (if applicable): system-config-users-1.2.19-1 How reproducible: Always 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:
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 admin context.
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: 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 better. 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 upstream). 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. ***