Need a mechanism to disable glibc rseq for binaries with capabilities

[Ashok Dwarakinath]

Hi Florian,

Sorry for the delayed response. The proposed solution will work for us. We do control how we setup the environment.

Thanks,
Ashok

On 2/26/26, 5:49 AM, "Florian Weimer" <fweimer@redhat.com <mailto:fweimer@redhat.com>> wrote:


!-------------------------------------------------------------------|
CAUTION: External Email


|-------------------------------------------------------------------!


* Ashok Dwarakinath:


> Hi folks,
>
> We have a binary with CAP_SYS_ADMIN capability that is started by a
> non-root user. This binary is linked to Google tcmalloc. The service
> has a lot of threads, so it benefits from tcmalloc per-CPU caches. We
> are migrating to glibc 2.34 (RHEL 9) which enables glibc rseq by
> default. This results in google tcmalloc disabling per-CPU cache
> support (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_google_tcmalloc_issues_144&d=DwIBAg&c=s883GpUCOChKOHiocYtGcg&r=heEgnzOSRce4-CB_b6veE4hSouVUUqPOE9cQdqFCMq8&m=L9KnByA95DSMR-YDcONgwPvf9_4GZXvW5iFJsDk3tQ-Ky-oXVagNtPh_UPSiZxMk&s=qcSB0I3hjLHwMeU1agI30txDVmTwDoBq9-t3ZojKRP0&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_google_tcmalloc_issues_144&d=DwIBAg&c=s883GpUCOChKOHiocYtGcg&r=heEgnzOSRce4-CB_b6veE4hSouVUUqPOE9cQdqFCMq8&m=L9KnByA95DSMR-YDcONgwPvf9_4GZXvW5iFJsDk3tQ-Ky-oXVagNtPh_UPSiZxMk&s=qcSB0I3hjLHwMeU1agI30txDVmTwDoBq9-t3ZojKRP0&e=> ). We found
> that disabling rseq using GLIBC_TUNABLES doesn't work for binaries
> with capabilities set. So, we need a different mechanism to make this
> work. Thoughts?


There might be a way to address this gap using path-based filters in
system-wide tunables:


[PATCH v5 4/4] Add system-wide tunables: Filters
<https://urldefense.proofpoint.com/v2/url?u=https-3A__inbox.sourceware.org_libc-2Dalpha_ddd06f961f6ef2c38838ae5775e630e7ec4d86ef.1770786739.git.dj-40redhat.com_&d=DwIBAg&c=s883GpUCOChKOHiocYtGcg&r=heEgnzOSRce4-CB_b6veE4hSouVUUqPOE9cQdqFCMq8&m=L9KnByA95DSMR-YDcONgwPvf9_4GZXvW5iFJsDk3tQ-Ky-oXVagNtPh_UPSiZxMk&s=M-ItqNoy92DDt4rXgQsl7BHZXoMWgBJc-WFYg-EkeKI&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__inbox.sourceware.org_libc-2Dalpha_ddd06f961f6ef2c38838ae5775e630e7ec4d86ef.1770786739.git.dj-40redhat.com_&d=DwIBAg&c=s883GpUCOChKOHiocYtGcg&r=heEgnzOSRce4-CB_b6veE4hSouVUUqPOE9cQdqFCMq8&m=L9KnByA95DSMR-YDcONgwPvf9_4GZXvW5iFJsDk3tQ-Ky-oXVagNtPh_UPSiZxMk&s=M-ItqNoy92DDt4rXgQsl7BHZXoMWgBJc-WFYg-EkeKI&e=> >


Ashok, would this cover your scenario? Would you be able to ship an
ldconfig configuration file along with your application that marks its
installation path as trusted and applies tunables to it?


Thanks,
Florian