ModSecurity 3.0.14 configure script fails to detect lib64-installed YAJL, LMDB, and PCRE2
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
- #3406 di @JustCoding247 — chiusa senza merge
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Ferma
- Stack tecnologico
- shell
- Ambito
- build-system
Direzione di ricerca
Iniziare con i controlli dello script configure alle righe 7096, 7164, 7870, 7945, 9086 e 9161, confrontando la gestione di lib/ e lib/x86_64-linux-gnu/ con i controlli MaxMind esistenti. Riprodurre il problema utilizzando il comando ./configure fornito e verificare che YAJL, LMDB e PCRE2 installati in lib64 vengano rilevati e che la compilazione abbia esito positivo.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Describe the bug
The configure script in ModSecurity 3.0.14 fails to detect YAJL, LMDB, and PCRE2 libraries when they are installed in lib64 directories, causing compilation failures in container environments and various Linux distributions.
Logs and dumps
Configure script error output:
configure: error: YAJL was explicitly referenced but it was not found
configure: error: LMDB was explicitly referenced but it was not found
configure: error: PCRE2 was explicitly referenced but it was not found
To Reproduce
Steps to reproduce the behavior:
- Install YAJL, LMDB, or PCRE2 libraries in
/usr/local/[library]/lib64/directory - Run ModSecurity 3.0.14 configure script:
./configure --with-yajl=/usr/local/yajl-2.1.0 \ --with-lmdb=/usr/local/lmdb-0.9.33 \ --with-pcre2=/usr/local/pcre2-10.45 - Configure script fails to detect libraries despite correct installation paths
Expected behavior
The configure script should successfully detect YAJL, LMDB, and PCRE2 libraries when they are installed in standard lib64 directories, similar to how MaxMind and other libraries are detected.
Root Cause
The configure script's library detection logic only checks lib/ and lib/x86_64-linux-gnu/ directories but lacks support for the standard lib64/ directory where 64-bit libraries are commonly installed.
Affected Libraries
- YAJL (Yet Another JSON Library) - Detection fails at configure script lines 7096, 7164
- LMDB (Lightning Memory-Mapped Database) - Detection fails at lines 7870, 7945
- PCRE2 (Perl Compatible Regular Expressions 2) - Detection fails at lines 9086, 9161
Current Library Detection Pattern
The configure script currently checks:
# 1. Standard lib directory
if test -e "${path}/lib/lib${z}.${y}"; then
yajl_lib_path="${path}/lib/"
# ...
fi
# 2. Debian/Ubuntu specific path
if test -e "${path}/lib/x86_64-linux-gnu/lib${z}.${y}"; then
yajl_lib_path="${path}/lib/x86_64-linux-gnu/"
# ...
fi
# Missing: lib64 directory check
Proposed Solution
Add lib64 directory detection between existing checks, following the same pattern already implemented for MaxMind and other libraries:
# Add this check between lib/ and lib/x86_64-linux-gnu/
if test -e "${path}/lib64/lib${z}.${y}"; then
yajl_lib_path="${path}/lib64/"
yajl_lib_name="${z}"
yajl_lib_file="${yajl_lib_path}/lib${z}.${y}"
break
fi
Server (please complete the following information):
- ModSecurity version (and connector): ModSecurity v3.0.14
- WebServer: N/A (compilation issue)
- OS (and distro): Multiple distributions affected:
- Alma Linux 9, 10
- CentOS Stream 9, 10
- Oracle Linux 9, 10
- Rocky Linux 9, 10
- Ubuntu 22.04, 24.04
- Debian 12, 13
Rule Set (please complete the following information):
- Running any public or commercial rule set? N/A (compilation stage issue)
- What is the version number? N/A
Additional context
Impact
- High: Prevents ModSecurity compilation in affected environments
- Widespread: Affects multiple Linux distributions and container builds
- Blocking: No workaround available without source code modification
Related Issues
- #3318 - Similar PCRE2 detection issue reported recently
Additional Information
- Libraries with existing lib64 support (no changes needed): MaxMind, CURL, GeoIP
- This issue is specific to ModSecurity 3.0.14; other versions not tested
- All existing functionality would be preserved with this fix
- Library Installation: Libraries correctly installed in
/usr/local/[library]/lib64/directories
Willingness to Contribute
I have developed and tested a complete patch for this issue across all affected distributions and am ready to submit a Pull Request if this approach is acceptable to the maintainers.
- Lingua principale
- C++
- Stelle
- 9.8k
- Fork
- 1.8k
- Merge medio
- 1g 1h
- PR unite (30g)
- 10
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di owasp-modsecurity/ModSecurity
-
v2: t:utf8toUnicode drops the last hex digit of code points above U+FFFF (regression since 2.9.9)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
owasp-modsecurity/ModSecurity#3684 ·
I maintainer di solito rispondono entro 1 giorno
-
IIS: ReadFileChunk allocates only 1 byte but reads m_dwPageSize (latent overflow)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta2.x bug Platform - IIS pr available windows
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
owasp-modsecurity/ModSecurity#3623 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
IIS: Host header fallback is dead code (r->hostname == NULL can never be true)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta2.x bug Platform - IIS pr available windows
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
owasp-modsecurity/ModSecurity#3621 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
IIS: Content-Length header corrupted/truncated for large responses (wrong printf format + off-by-one buffer size)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta2.x bug Platform - IIS pr available windows
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
owasp-modsecurity/ModSecurity#3619 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
2.x bug Platform - IIS pr available windows
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
owasp-modsecurity/ModSecurity#3612 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di owasp-modsecurity/ModSecurity
Issue simili
-
[Cleanup] Include the public header in work_split.cppForse già presa @blozano-tt l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
tenstorrent/tt-metal#60850 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
beehive-lab/TornadoVM#1248 ·
I maintainer di solito rispondono entro 1 giorno
-
core: RAC_LLM_OPTIONS_DEFAULT.min_p disagrees with the IDL's annotated defaultForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug core p3
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
RunanywhereAI/runanywhere-sdks#1083 ·
I maintainer di solito rispondono entro 5 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
tesseract-ocr/tesseract#4653 ·
I maintainer di solito rispondono entro 1 giorno
-
area: docs eco: cpp good first issue help wanted lane: free-agent roadmap size: XS type: docs
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
arminazimi/evergreen#475 ·
I maintainer di solito rispondono entro 1 giorno