ModSecurity 3.0.14 configure script fails to detect lib64-installed YAJL, LMDB, and PCRE2
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
- #3406 de @JustCoding247 — cerrado sin fusionar
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Estancado
- Stack tecnológico
- shell
- Área
- build-system
Línea de trabajo
Comience con las comprobaciones del script configure en las líneas 7096, 7164, 7870, 7945, 9086 y 9161, comparando su gestión de lib/ y lib/x86_64-linux-gnu/ con las comprobaciones existentes de MaxMind. Reproduzca el problema utilizando el comando ./configure proporcionado y verifique que se detectan YAJL, LMDB y PCRE2 instalados bajo lib64 y que la compilación se completa correctamente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- C++
- Estrellas
- 9.8k
- Forks
- 1.8k
- Merge medio
- 1 d 1 h
- PR fusionados (30 d)
- 13
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de owasp-modsecurity/ModSecurity
-
v2: t:utf8toUnicode drops the last hex digit of code points above U+FFFF (regression since 2.9.9)Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
owasp-modsecurity/ModSecurity#3684 ·
Los mantenedores suelen responder en 1 día
-
IIS: ReadFileChunk allocates only 1 byte but reads m_dwPageSize (latent overflow)Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto2.x bug Platform - IIS pr available windows
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
owasp-modsecurity/ModSecurity#3623 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
IIS: Host header fallback is dead code (r->hostname == NULL can never be true)Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto2.x bug Platform - IIS pr available windows
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
owasp-modsecurity/ModSecurity#3621 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
IIS: Content-Length header corrupted/truncated for large responses (wrong printf format + off-by-one buffer size)Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto2.x bug Platform - IIS pr available windows
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
owasp-modsecurity/ModSecurity#3619 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
2.x bug Platform - IIS pr available windows
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
owasp-modsecurity/ModSecurity#3612 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de owasp-modsecurity/ModSecurity
Issues similares
-
Plugin storage: send reason codes, not English sentences, so the overview can translate themAbiertoenhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
prestonbrown/helixscreen#1867 ·
Los mantenedores suelen responder en 2 días
-
bug P5 XS
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
open-astro/AlpacaBridge#1550 ·
Los mantenedores suelen responder en 1 día
-
Component: Packaging Type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
LizardByte/libvirtualhid#204 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Niko1221/Strata#3785 · 2 comentarios ·
Los mantenedores suelen responder en 3 días