Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

OAuth (bearer) quota check denies every user when the allowed-user list is empty

Abierto Apto para principiantes
  • ¿Algo no está bien?
#1,795 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
66/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
c
Área
authorization, backend

Línea de trabajo

Empieza en scheduler/ipp.c, en add_job(), alrededor de la devolución temprana y la rama bearer en las líneas 3876-3915, y luego compáralo con la rama protegida no bearer en la línea 3916. El error es que la comparación bearer se ejecuta cuando la lista de usuarios permitidos está vacía, por lo que una impresora limitada por cuota rechaza a todos los usuarios OAuth. Está terminado cuando una lista de permitidos vacía permite a los usuarios OAuth del mismo modo que la ruta no bearer. Puedes comprobarlo configurando una cuota de trabajos en una impresora sin lista de usuarios y enviando un trabajo autenticado con bearer.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary
Before checking the allowed-user list, add_job() returns early only when the list is empty and both quotas are zero. A printer that has a quota set therefore proceeds with an empty list. The non-bearer path then guards the comparison with cupsArrayCount(p->users), so an empty list means "no restriction". The bearer path does not guard it: the loop over the empty list leaves name as NULL, and the comparison at 3910 evaluates (name != NULL) == p->deny_users, which is true for the default allow-list, so every OAuth user is refused.

Affected code: scheduler/ipp.c:3876–3915, specifically the early-out at 3876–3877, the bearer branch at 3879, the unguarded comparison at 3910, and the guarded non-bearer branch at 3916. Unchanged in current master 3949d140567cf7b6cede1ea48e4ca6db92066c91.

Reachable rejection sequence

  1. A printer is configured with a quota, for example lpadmin -p printer1 -o job-k-limit=100, and its allowed-user list is left empty — the ordinary way to mean "anyone may print".
  2. The early-out at 3876 does not apply, because the quota is non-zero even though the list is empty.
  3. cupsdDefaultAuthType() is CUPSD_AUTH_BEARER, so execution enters the branch at 3879.
  4. The loop at 3885 does not execute, since p->users is empty; name keeps its NULL value.
  5. Line 3910 evaluates (0) == p->deny_users. With the list used as an allow-list, deny_users is false, so the comparison is true and line 3913 refuses the job.
  6. The same printer accepts the identical request over any non-bearer authentication path, because that branch is only entered when the list is non-empty (3916).

The result is that a quota-limited printer is unusable for OAuth users, and the log line reads "Denying user ... access to printer ...", which suggests an access-control decision rather than a missing empty-list case. Nothing is granted that should not be, so this is functional rather than a bypass.

Suggested fix
Guard the comparison the same way the non-bearer branch does.

-    if ((name != NULL) == p->deny_users)
+    if (cupsArrayCount(p->users) > 0 && (name != NULL) == p->deny_users)

Two neighbouring issues in the same function, not worth separate reports but visible in the same code: at 4009–4021 a failed mbr_user_name_to_uuid() is logged and the loop continues to uuid_compare() with usr2_uuid unset on the first pass, where a continue is expected; and at 3967–3994 a failed group-name conversion does not clear grp_uuid before mbr_check_membership(), unlike the @# branch above it. Both compile only in HAVE_MBR_UID_TO_UUID builds.

Lenguaje dominante
C
Estrellas
1.8k
Forks
353
Merge medio
19 h 41 min
PR fusionados (30 d)
18

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenPrinting/cups

Todos los issues de OpenPrinting/cups

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.