… ya que no siempre existe una correlación entre el usuario que crea los trabajos de impresión y el que tiene que acceder a ellos.

Ya comenté cómo he aprovechado el anclaje de cups-pdf para posprocesar los documentos PDF y enviarlos a una o varias cuentas de correo electrónico. Y sí, funciona bien, pero también necesitan que dichos documentos se instalen en las carpetas correspondientes para que tengan acceso desde su escritorio (existe un montaje NFS y un enlace simbólico en cada puesto de trabajo).

Estuve dándole vueltas y me percaté de que podía crear un envoltorio de posproceso que hiciese más de una cosa. Sirve de puente entre el programa de cups-pdf y el añadido que hice para enviar correo y que he llamado cups-pdf2email. Además de a éste también llama a cups-pdf2copy, un script que consulta un archivo mapa y copia los PDF generados a otros directorios. No he tenido tiempo ni ganas de establecer mejores controles sobre la ejecución de todos ellos. Son tan simples que confío en una búsqueda en los registros de cups en caso de fallos catastróficos. Tal vez más adelante si es que lo usan mucho.

Bien, el caso es que por motivos de seguridad cups-pdf funciona siempre con los permisos de la cuenta de usuario que ha creado el trabajo de impresión o, en caso de no encontrarlo por no existir correspondencia con el sistema donde se originó, una cuenta anónima. Y aquí es donde tenemos el mayor escollo para que el resultado sea correcto: los permisos de acceso.

Cada usuario tiene su propio directorio de documentos PDF que importa directamente en su máquina utilizando NFS y autofs. Como es normal no debe poder escribir, ni siquiera leer, de los directorios de los demás aunque tenga un acceso indirecto hacia ellos.

Por si alguien se ha liado lo que hago es importar un recurso NFS llamado

/var/pdf

de donde cuelgan directorios con el nombre del usuario. El script de arranque de sesión mantiene un enlace simbólico de

$HOME/Archivos/PDF -> /var/pdf/$USER

. Es posible entonces acceder a los PDF de otro usuario como 

/var/pdf/OTRO

pero las carpetas no suelen tener permisos más allá de lectura del índice.

Así pues nos encontramos con que el script que debe copiar un documento PDF a otras carpetas se encuentra funcionando bajo la identidad de un usuario local y necesita permisos para instalar dichos archivos en carpetas de otros usuarios con los permisos suficientes para que puedan leerlas.

$ install -u $USER $PDF /var/pdf/$USER

Tan simple como eso. Pero desde hace mucho, mucho tiempo, los scripts no pueden utilizar el mecanismo setuid de los sistemas UNIX debido a los graves problemas de seguridad que pueden producir. ¿ Qué hacemos entonces ? Hay un par de soluciones que pueden más o menos funcionar:

• Dar permisos de uso del programa install a todos los usuarios que puedan utilizar la impresora virtual. En este caso concreto todas las cuentas tienen como atributo común el que pertenecen a un grupo con el nombre de la empresa. Y ahí sí que podemos emplear sudo.
• Usar un programa lanzadera que sí que funcione con permisos administrativos vía setuid e indicarle que sea él que lance el programa de copia. Y buscando, buscando, he encontrado una referencia a un programa -empaquetado para Debian- llamado super.

Tenía pensado hacer algunas pruebas pero me han quitado el poco tiempo que tenía para ello: necesitan que funcione ya y me he inclinado por emplear la opción de sudo dado que es la menos costosa. Puedo incluir el fragmento de configuración en el paquete que configura las impresoras y retocar mínimamente el script de copia para que todo funcione.

super, por otra parte, es algo más engorroso de usar. No sé si por la redacción de la documentación o por el concepto en sí, pero no es fácil hallar ejemplos simples.

Así que al final he creado el siguiente archivo en

/etc/sudoers.d/cups-pdf

con el contenido

# Mantenemos el entorno
Defaults       env_keep += MAINTAINER

# Los miembros del grupo empresa pueden usar, sin 
# contraseña, el script de copia
%Empresa ALL=NOPASSWD: /usr/bin/cups-pdf2copy

Y en el script envoltorio que lanza las dos tareas, el envío de email y la copia de documentos, sólo necesita prefijar la llamada a éste último con el programa sudo:

#   PDF enviado por email
/usr/bin/cups-pdf2email "$PDF" "$USER"

#   PDF copiado en otros directorios
sudo /usr/bin/cups-pdf2copy "$PDF" "$USER"

Y jo, funciona muy bien. El riesgo de seguridad se reduce bastante porque no doy permisos de acceso directo para el programa install; menos mal, porque estaba de lo más incómodo con la medida.