XrdMacaroon segfaults on client auth (RHEL8 host)

[mdoidge]

OS: Rocky Linux release 8.5 (Green Obsidian) 4.18.0-348.12.2.el8_5.x86_64
Versions: libmacaroons-0.3.0-6.el8.x86_64
xrootd-server-5.4.0-2.el8.x86_64

Hello,
Whilst attempting to setup an xrootd server with http tpc support at our site we ran into an issue where the xroot service would segfault every time an http request was made against it[1]. We ran the same config on a CentOS7 test box and had no issues.

Colleagues in the UK tracked the issue to this segment of the code:
https://github.com/xrootd/xrootd/blob/master/src/XrdMacaroons/XrdMacaroonsHandler.cc#L571-L572

It's been the long time since I've done much C/C++ work and I'm mainly paraphrasing here, but AIUI the action of preallocating a vector with space from reserve then pointing to the start of a reserve to create a buffer does not work under the stricter checking of found in RHEL8 (and by extension RHEL8 clones, and probably RHEL9).

Suggested by the same learned colleagues in the UK, a fix could look like:

• std::vector macaroon_resp; macaroon_resp.reserve(size_hint);
• if (macaroon_serialize(mac_with_date, &macaroon_resp[0], size_hint, &mac_err))

• std::unique_ptr<char[]> macaroon_resp(new char[size_hint]);
• if (macaroon_serialize(mac_with_date, macaroon_resp.get(), size_hint, &mac_err))
  (And the same for the later references to &macaroon_resp[0] on line 584).

This issue has makes running xrootd RHEL8 clones impossible until fixed - and would likely extend to RHEL9. As many sites in the UK are planning to migrate to a filesystem fronted by an xrootd+http server this is of great interest, especially as many are installing on a RHEL8 clone as default practice.

Many thanks,
Matt
Lancaster Site Admin

[1] Stacktrace example for a crashing thread(logs just abruptly stop):
#0 0x00007f42f000737f raise (libc.so.6)
#1 0x00007f42efff1db5 abort (libc.so.6)
#2 0x00007f42e54283c8 ZSt20__replacement_assertPKciS0_S0 (libXrdMacaroons-5.so)
#3 0x00007f42e5426079 _ZNSt6vectorIcSaIcEEixEm (libXrdMacaroons-5.so)
#4 0x00007f42e54280d1 _ZN9Macaroons7Handler10ProcessReqER13XrdHttpExtReq (libXrdMacaroons-5.so)
#5 0x00007f42eb282cf3 _ZN10XrdHttpReq14ProcessHTTPReqEv (libXrdHttpUtils.so.2)
#6 0x00007f42eb27a064 _ZN15XrdHttpProtocol7ProcessEP7XrdLink (libXrdHttpUtils.so.2)
#7 0x00007f42f13c0b4d _ZN10XrdLinkXeq4DoItEv (libXrdUtils.so.3)
#8 0x00007f42f13bd1aa _ZN7XrdLink11setProtocolEP11XrdProtocolbb (libXrdUtils.so.3)
#9 0x00007f42f13c4017 _ZN12XrdScheduler3RunEv (libXrdUtils.so.3)
#10 0x00007f42f13c413d _Z15XrdStartWorkingPv (libXrdUtils.so.3)
#11 0x00007f42f134baeb XrdSysThread_Xeq (libXrdUtils.so.3)
#12 0x00007f42f039d17a start_thread (libpthread.so.0)
#13 0x00007f42f00ccdc3 __clone (libc.so.6)

[simpsonst]

vector::resize instead of vector::reserve might do it. The latter ensures allocation, but doesn't set the size, and it's vector::operator[] that has the failing assertion based on the index 0 not being less than the size 0.

[abh3]

Could you generate a pull request to fix the problem? That way you get recognition for tracking this down.