Package: cpu Version: 1.4.3-1 Severity: important i'm using cpu for ldap administration, and regardless of the usermod operation asked for (eg changing the gecos, password...) cpu wipes all supplementary group memberships.
this is pretty annoying and hard to recover automatically, as it would mean that whoever invokes cpu has to parse cpu cat first to figure out the old memberships and fake a -G arg to cpu usermod. example: $ cpu cat|fgrep guest .... guest:x:3009:3034:Some Guest:/home/guest:/bin/bash uml-net:x:101: ... guest, ... audio:x:29: ... guest ... guest:x:3034: $ cpu usermod -c "Still a Guest" guest User guest successfully modified! $ cpu cat |fgrep guest guest:x:3009:3034:Still a Guest:/home/guest:/bin/bash guest:x:3034: if i add the old groups with -G to the -c invocation, then and only then they stay. i've dug into this a bit, and as far as i understand the flow of execution in the relevant code, stuff around line 202 of src/plugins/ldap/ld.c is where things go wrong: globalldap->memberuid is not set from anywhere (AFAICT only commandline.c does that, but only if we explicitly hand over a -G arg), and checkSupGroups comes back immediately. now rmUsrFrmOldSupGrp removes the group membership attributes from ldap, but without propagating anything back to globalldap->memberuid... next ldapusermod is called to do the real work. this runs ldapusercheck which only looks at the blank globalldap->memberuid. nobody picks up the old groups and the subsequent call to ldap_modify_s in ldapusermod doesn't re-add those group memberships as apparently intended. it seems to me that rmUsrFrmOldSupGrp should actually populate the globalldap->memberuid array to fix the problem. i'm not 100% certain of this assessment of the code in question, but i think it should serve as a starting point for tracking down the problem. regards az -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
