Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) Enabling memberof overlay on frontend database causes slapd to SEGFAULT due to stack overflow when renaming an entry. Slapd should not segfault even if the configuration is wrong. Initial server configuration: (slapadd -F /etc/openldap/slapd.d -n 0 -l slapd.ldif) dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd.args olcPidFile: /var/run/slapd.pid dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,c n=auth" manage by * none dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: dc=my-domain,dc=com olcRootDN: cn=Manager,dc=my-domain,dc=com olcRootPW: secret olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq Initial data: (ldapadd -c -H ldap://localhost -x -D cn=manager,dc=my-domain,dc=com -w secret -f data.ldif) dn: dc=my-domain,dc=com objectclass: dcObject objectclass: organization o: Example Org dc: my-domain dn: cn=Manager,dc=my-domain,dc=com objectclass: organizationalRole cn: Manager dn: ou=users,dc=my-domain,dc=com objectclass: organizationalUnit ou: users dn: cn=foo,ou=users,dc=my-domain,dc=com objectclass: organizationalRole cn: foo Enabling overlay: (ldapadd -c -Y EXTERNAL -H ldapi:/// -f data_overlays.ldif) dn: olcOverlay={0}memberof,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: error olcMemberOfDanglingError: constraintViolation olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf Renaming the entries, causing segmentation fault: (ldapmodify -c -H ldap://localhost -x -D cn=manager,dc=my-domain,dc=com -w secret -f data_modify.ldif) dn: cn=foo,ou=users,dc=my-domain,dc=com changetype: modrdn newrdn: cn=bar deleteoldrdn: 1 dn: cn=bar,ou=users,dc=my-domain,dc=com changetype: modrdn newrdn: cn=foo deleteoldrdn: 1 Server backtrace: (gdb) bt 6 full #0 0x000000000044f188 in backend_check_restrictions (op=0x0, rs=0x0, opdata=0x0) at ../../../servers/slapd/backend.c:1022 restrictops = 140737153878880 requires = 4515244 opflag = 8413346912 exopflag = 140737311768104 ssfs = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0} ssf = 0xa0bc30 updateop = 0 starttls = 0 session = -184966544 #1 0x000000000043f3cf in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:370 bd = 0x7ffff4f9a180 #2 0x00000000004d9fd4 in overlay_op_walk (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search, oi=0x7fffec104b60, on=0x0) at ../../../servers/slapd/backover.c:671 func = 0x8dc018 rc = 32768 #3 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 oi = 0x7fffec104b60 on = 0x7fffec104d40 be = 0xa0bc30 db = {bd_info = 0x8dbfc0, bd_self = 0xa0bc30, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001", '\000' <repeats 16 times>, "\001", be_flags = 67848, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0xa16380, be_nsuffix = 0xa163b0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0xa16450 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0xa164a0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0xa16320 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xbefb60, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x8d4c60, be_private = 0xa11e80, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff4f9a410, sc_response = 0x4d8d5b <over_back_response>, sc_cleanup = 0, sc_private = 0x7fffec104b60} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #4 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 No locals. #5 0x000000000043f5bb in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:402 bd = 0x7ffff4f9a460 (More stack frames follow...) ... #45535 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 #45536 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 #45537 0x000000000043f5bb in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:402 #45538 0x00000000004d9fd4 in overlay_op_walk (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search, oi=0x7fffe81050a0, on=0x0) at ../../../servers/slapd/backover.c:671 #45539 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 #45540 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 #45541 0x00000000005abaeb in memberof_isGroupOrMember (op=0x7fffec000940, mci=0x7fffec001420) at ../../../../servers/slapd/overlays/memberof.c:289 #45542 0x00000000005b00c0 in memberof_res_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../../servers/slapd/overlays/memberof.c:1513 #45543 0x000000000045262c in slap_response_play (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:507 #45544 0x0000000000452868 in send_ldap_response (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:582 #45545 0x0000000000453a52 in slap_send_ldap_result (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:860 #45546 0x000000000050e0a9 in bdb_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../../servers/slapd/back-bdb/modrdn.c:789 #45547 0x00000000004626be in fe_op_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/modrdn.c:314 #45548 0x00000000004d9fd4 in overlay_op_walk (op=0x7fffec000940, rs=0x7ffff57989e0, which=op_modrdn, oi=0x7fffe81050a0, on=0x0) at ../../../servers/slapd/backover.c:671 #45549 0x00000000004da225 in over_op_func (op=0x7fffec000940, rs=0x7ffff57989e0, which=op_modrdn) at ../../../servers/slapd/backover.c:723 #45550 0x00000000004da3b2 in over_op_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/backover.c:768 #45551 0x0000000000461e20 in do_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/modrdn.c:186 #45552 0x000000000043a9df in connection_operation (ctx=0x7ffff5798b20, arg_v=0x7fffec000940) at ../../../servers/slapd/connection.c:1150 #45553 0x000000000043af9c in connection_read_thread (ctx=0x7ffff5798b20, argv=0x13) at ../../../servers/slapd/connection.c:1286 #45554 0x00000000005d0dd2 in ldap_int_thread_pool_wrapper (xpool=0x9b0170) at ../../../libraries/libldap_r/tpool.c:688 #45555 0x00000034ad607b41 in start_thread (arg=0x7ffff5799700) at pthread_create.c:305 #45556 0x00000034acee0e6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
changed state Open to Active
Hello, > Enabling memberof overlay on frontend database causes slapd to > SEGFAULT due to stack overflow when renaming an entry. please, can somebody confirm that this configuration is wrong and that it should not be allowed? Or that this configuration is correct and the "overlay effect" should be inherited by backend database? I would like to help with fixing this, but I have no idea what is the expected behavior. Documentation says nothing about this. Jan
> Hello, > >> Enabling memberof overlay on frontend database causes slapd to >> SEGFAULT due to stack overflow when renaming an entry. > > please, can somebody confirm that this configuration is wrong and > that it should not be allowed? Or that this configuration is > correct and the "overlay effect" should be inherited by backend > database? > > I would like to help with fixing this, but I have no idea what > is the expected behavior. Documentation says nothing about this. What happens is that the memberof overlay, when stacked on the frontend database, keeps looping until the stack is exhausted, since internal modifications keep calling the frontend's modify hook rather than the actual one that needs to be called. I don't recall testing it this way during development, but I don't see any reason to prevent it from working this way. Feel free to look at it, I probably won't have time to do it soon. Thanks, p.
> What happens is that the memberof overlay, when stacked on the frontend > database, keeps looping until the stack is exhausted, since internal > modifications keep calling the frontend's modify hook rather than the > actual one that needs to be called. I have no idea how to fix it. I probably do not understand the manipulation with BackedInfo structures fully. It is obious that it is caused by doing a search from the modrdn operation callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). Other backends does not call any backend operation at the same moment (op->callback). Frontend fe_op_search() is called. It tries to choose the right backend with select_backend(). Which returns the overlay backend (bi_type == "over"), over_op_walk() then selects fe_op_search() again, and we are looping infinitely. I have no clue how to hide or temporarily deactivate the overlay in memberof_res_modrdn() to make the select_backend() function to choose the right underlaying backend. Or maybe I have choosen a wrong way of fixing it. All ideas are welcomed. :-) Thanks & Regards, Jan
jvcelak@redhat.com wrote: >> What happens is that the memberof overlay, when stacked on the frontend >> database, keeps looping until the stack is exhausted, since internal >> modifications keep calling the frontend's modify hook rather than the >> actual one that needs to be called. > > I have no idea how to fix it. I probably do not understand the manipulation > with BackedInfo structures fully. > > It is obious that it is caused by doing a search from the modrdn operation > callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). Other > backends does not call any backend operation at the same moment (op->callback). > > Frontend fe_op_search() is called. It tries to choose the right backend with > select_backend(). Which returns the overlay backend (bi_type == "over"), > over_op_walk() then selects fe_op_search() again, and we are looping infinitely. > > I have no clue how to hide or temporarily deactivate the overlay in > memberof_res_modrdn() to make the select_backend() function to choose the right > underlaying backend. Or maybe I have choosen a wrong way of fixing it. > > All ideas are welcomed. :-) The attached diff fixes this particular problem. I haven't spent any time to see if the other be_* invocations need to be protected the same way. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Friday 27 of April 2012 12:26:22, Howard Chu wrote: > jvcelak@redhat.com wrote: > >> What happens is that the memberof overlay, when stacked on the frontend > >> database, keeps looping until the stack is exhausted, since internal > >> modifications keep calling the frontend's modify hook rather than the > >> actual one that needs to be called. > > > > I have no idea how to fix it. I probably do not understand the > > manipulation > > with BackedInfo structures fully. > > > > It is obious that it is caused by doing a search from the modrdn operation > > callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). > > Other backends does not call any backend operation at the same moment > > (op->callback). > > > > Frontend fe_op_search() is called. It tries to choose the right backend > > with select_backend(). Which returns the overlay backend (bi_type == > > "over"), over_op_walk() then selects fe_op_search() again, and we are > > looping infinitely. > > > > I have no clue how to hide or temporarily deactivate the overlay in > > memberof_res_modrdn() to make the select_backend() function to choose the > > right underlaying backend. Or maybe I have choosen a wrong way of fixing > > it. > > > > All ideas are welcomed. :-) > > The attached diff fixes this particular problem. I haven't spent any time to > see if the other be_* invocations need to be protected the same way. Thank you. I have added this check to another places (attaching patch). But it seems that it is not sufficient. In certain situations I can still trigger the segfault - from memberof_res_modrdn() by calling backend_attribute(). At a first glance, the circumstances are a little bit different but I see no difference in the structures when calling the function with overlay set on frontend and backend database. I hope I will have some time to look at it soon. (gdb) bt -30 #35697 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35698 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35699 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35700 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35701 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35702 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35703 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35704 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35705 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35706 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35707 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35708 0x000000000044fc46 in be_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backend.c:1366 #35709 0x0000000000450990 in fe_acl_attribute (op=0x7fffe40028f0, target=0x0, edn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backend.c:1658 #35710 0x00000000004d9cdb in over_acl_attribute (op=0x7fffe40028f0, target=0x0, entry_ndn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backover.c:589 #35711 0x0000000000450ed5 in backend_attribute (op=0x7fffe40028f0, target=0x0, edn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backend.c:1778 #35712 0x00000000005a4c9f in memberof_res_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../../servers/slapd/overlays/memberof.c:1558 #35713 0x000000000045252c in slap_response_play (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:507 #35714 0x0000000000452768 in send_ldap_response (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:582 #35715 0x0000000000453952 in slap_send_ldap_result (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:860 #35716 0x000000000050dfa9 in bdb_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../../servers/slapd/back-bdb/modrdn.c:789 #35717 0x00000000004625be in fe_op_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/modrdn.c:314 #35718 0x00000000004d9ed4 in overlay_op_walk (op=0x7fffe40028f0, rs=0x7ffff23d9a60, which=op_modrdn, oi=0x7fffe41050e0, on=0x0) at ../../../servers/slapd/backover.c:671 #35719 0x00000000004da125 in over_op_func (op=0x7fffe40028f0, rs=0x7ffff23d9a60, which=op_modrdn) at ../../../servers/slapd/backover.c:723 #35720 0x00000000004da2b2 in over_op_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/backover.c:768 #35721 0x0000000000461d20 in do_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/modrdn.c:186 #35722 0x000000000043a8df in connection_operation (ctx=0x7ffff23d9ba0, arg_v=0x7fffe40028f0) at ../../../servers/slapd/connection.c:1150 #35723 0x000000000043ae9c in connection_read_thread (ctx=0x7ffff23d9ba0, argv=0x15) at ../../../servers/slapd/connection.c:1286 #35724 0x00000000005d12ce in ldap_int_thread_pool_wrapper (xpool=0x9b0bf0) at ../../../libraries/libldap_r/tpool.c:688 #35725 0x00007ffff73e4d90 in start_thread () from /lib64/libpthread.so.0 #35726 0x00007ffff5cf5f5d in clone () from /lib64/libc.so.6
Hello, is anybody working on this issue? I've the same problem. I tried the following patch and it works for me. Why isn't it applied here. https://bugs.archlinux.org/task/38137?getfile=11329 Debian Wheezy openldap_2.4.31 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none modulepath /usr/lib/ldap moduleload back_bdb moduleload memberof.la overlay memberof ####################################################################### # Specific Backend Directives for @BACKEND@: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend bdb With friendly regards Harald Winkelmann Software Development DAM Group GmbH Planckstraße 7 88677 Markdorf
harald.winkelmann@bertschinnovation.com wrote: > Debian Wheezy > openldap_2.4.31 Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? Ciao, Michael.
>Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? This is the actual openldap version distributed with the actual debian stable version (wheezy). I just made a full dist-upgrade and run into this problem. This thread is still active. So... Harry
harald.winkelmann@bertschinnovation.com wrote: >> Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? > > This is the actual openldap version distributed with the actual debian stable version (wheezy). Whatever Debian considers "stable" (for what definition?) is not relevant for OpenLDAP. Personally I consider the Debian packages rather unmaintained. Ciao, Michael.
I had the same issue under Arch with OpenLDAP 2.4.39. The patch from Arch bug tracker fixed the issue for me (https://bugs.archlinux.org/task/38137). Élie
harald.winkelmann@bertschinnovation.com wrote: > --_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hello, > > is anybody working on this issue? > I've the same problem. > I tried the following patch and it works for me. Why isn't it applied here. > https://bugs.archlinux.org/task/38137?getfile=3D11329 Probably because whoever submitted that patch to arch never submitted it here. Nor do I see any confirmation that it fixed all the cases as described in Followup #5 of this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes
partial fix in master partial fix in RE25 partial fix in RE24 commit 03d927485ef034169238004f5257c4a5f3694978
changed notes moved from Incoming to Software Bugs
note: memberof is deprecated with 2.5+, use dynlist instead
memberof is deprecated, any remaining issues will not be fixed.
Looking at the Arch patch, might be related to ITS#10135?
Looking to fix memberOf rather than deprecate, re-opening