#5367 Renaming user to invalid value using settatr results in segfault
Closed: Fixed None Opened 8 years ago by fskola.

While refactoring user plugin test from test_xmlrpc, I run into this issue.

This should be reproducible with current test_user_plugin using these steps:
https://paste.fedoraproject.org/278779/47540621/

Checked on a clean VM with last commit 2f34502.

System log:

Oct 13 18:29:43 hostname audit[23052]: ANOM_ABEND auid=4294967295 uid=989 gid=986 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pi
d=23052 comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11
Oct 13 18:29:43 hostname kernel: ns-slapd[23052]: segfault at 70 ip 00007f0cbe39940b sp 00007f0c927f0f20 error 6 in libslapd.so.0.0.0[
7f0cbe307000+121000]
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: ipa         : ERROR    syncrepl_poll: LDAP error ({'desc': "Can't contact LDAP server
"})
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: Traceback (most recent call last):
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 112, in <module>                                                                                 
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):                                                                                 
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 352, in syncrepl_pol                                                          
l                                                                                                                                                                                               
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: add_intermediates=1, add_ctrls=1, all = 0                                                                                                      
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 483, in result4                                                             
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_interme                                                          
diates,add_extop)                                                                                                                                                                               
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in _ldap_call                                                          
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: result = func(*args,**kwargs)                                                                                                                  
Oct 13 18:29:43 hostname ipa-dnskeysyncd[23397]: SERVER_DOWN: {'desc': "Can't contact LDAP server"}

I reproduced with two simple commands:

 ipa user-add
First name: user
Last name: 1
User login [u1]: 
---------------
Added user "u1"
---------------
  User login: u1
  First name: user
  Last name: 1
  Full name: user 1
  Display name: user 1
  Initials: u1
  Home directory: /home/u1
  GECOS: user 1
  Login shell: /bin/sh
  Kerberos principal: u1@ABC.IDM.LAB.ENG.BRQ.REDHAT.COM
  Email address: u1@abc.idm.lab.eng.brq.redhat.com
  UID: 1975400004
  GID: 1975400004
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False
[root@vm-192 ~]# ipa user-mod u1 --setattr=uid=+u2
ipa: ERROR: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket':

the problem is that "+" is a special char in an rdn

DS should not crash, but the test case is also invalid

Why do you think the test case is not valid?
In my view every data you can put in are 100% valid and the service should handle them (accept / reject / warn about) and definitely not crash itself.

Replying to [comment:3 alich]:

Why do you think the test case is not valid?
In my view every data you can put in are 100% valid and the service should handle them (accept / reject / warn about) and definitely not crash itself.

because "+" is special and should be escaped in an rdn, but looks like this is done behind the scenes in make_update_command.

I found that the crash is in the managed entry plugin and disbling this plugin makes the tescase succeed:

 ipa user-mod uone --setattr=uid=+3333
--------------------
Modified user "uone"
--------------------

resulting in

dn: uid=\2B3333,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com

wher the + is escaped

We also need IPA to properly handle DS error and give something reasonable rather than a cryptic socket error.

Thanks Ludwig for the new ticket and explanation.

Dmitri, I completely agree, errors should be more clear and user-friendly.

Actually the issue has not been fixed yet, the version of 1.3.4.5-1 still ends up with SIGSEGV (11). I haven't found 1.3.5, nor in COPR.[[BR]]
The final statement is to fix it in 1.3.5 and backport request for 1.3.4.5-1.[[BR]]
Let's have this track closed but for the bugfix progress watch the ds one: https://fedorahosted.org/389/ticket/48312

Metadata Update from @fskola:
- Issue assigned to someone
- Issue set to the milestone: FreeIPA 4.2.3

7 years ago

Login to comment on this ticket.

Metadata