Bug 133479
Summary: | system-config-users traceback when adding new user | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dave Cook <dave> | ||||||
Component: | libuser | Assignee: | Miloslav Trmač <mitr> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 3 | CC: | fkooman, nphilipp | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 0.51.12-1 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2004-09-24 16:41:24 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Dave Cook
2004-09-24 11:09:10 UTC
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. *** |