Samba AD e “force user” che non funziona (una soluzione)

Qualche giorno fa avevo chiesto informazioni su un problema in cui mi ero imbattuto con Samba. Le opzioni “force user” e “force group” sembrano non funzionare come mi aspettavo per le condivisioni di tipo stampante e questo, volendo passare lo spool di stampa a uno script, mi creava qualche problema di permessi.

Non sono riuscito a trovare una soluzione ottimale, ma grazie a uno spunto del buon CDF sono arrivato a un accrocchio che funziona piuttosto bene.

Situazione iniziale

Partiamo dal principio: su Samba 3.4 collegato a un dominio Active Directory su server Ubuntu 10.04, andiamo a creare una condivisione di tipo stampante che passi lo spool file generato ad uno script, per farne quello che riteniamo più opportuno:

[stampante]
printing = BSD
comment = Descrizione stampante
path = /path/dello/spool
read only = No
guest ok = Yes
printable = Yes
create mask = 0644
directory mask = 0744
use client driver = Yes
print command = /path/dello/spool/script.sh “%s” “%u”;
lpq command =
valid users = @”Domain Users”
force user = stampepdf
force group = stampepdf

Qualunque combinazione io abbia provato di “force user/group”, “create/directory mask” o altre opzioni, lo spool file creato in “/path/dello/spool” apparteneva sempre all’utente Active Directory che aveva lanciato la stampa, oltretutto con permessi 400, e lo script lanciato da “print command” veniva eseguito sempre con lo stesso utente.

Questa è una buona cosa, se non fosse che mi aspetterei qualcosa di diverso dai parametri “force user” e “force group”, e avevo deciso di avere una cartella di destinazione delle elaborazioni appartenente all’utente locale “stampepdf”, da condividere poi a sua volta sempre attraverso Samba.

Struttura delle directory

Ho creato l’utente “stampepdf” e la seguente struttura di directory, che mi permette una buona flessibilità in caso di future modifiche alla configurazione:

• /home/stampepdf/spool: contiene gli spool file creati da Samba quando un utente Windows lancia una stampa. I permessi sono impostati a 777 in modo che qualsiasi utente possa scrivere al suo interno
• /home/stampepdf/scripts: contiene gli script a cui dare in pasto gli spool file
• /home/stampepdf/stampe: contiene i file finali, risultato dell’elaborazione degli spool file da parte degli script. Verrà poi a sua volta condivisa (sempre grazie a Samba) in modo che gli utenti possano prelevare il risultato dell’elaborazione.

Configurazione di sudo

Ho poi configurato sudo (visudo è il comando da usare) in modo che qualsiasi utente (quindi anche quelli Active Directory) possa eseguire gli script in /home/stampepdf/scripts impersonando l’utente stampepdf senza che gli venga richiesta alcuna password:

ALL ALL=(stampepdf) NOPASSWD: /home/stampepdf/scripts/*.sh

Permessi dello spool file

A questo punto, rimane il problema dei permessi 600 sugli spool file creati da Samba, che vanno modificati almeno in 666 prima di poter elaborare il file con uno script lanciato dall’utente stampepdf. Per fare questo, ho creato un piccolo script (/home/stampepdf/spool.sh) che accetta un nome di file come parametro e non fa altro che modificarne i permessi in 666:

#!/bin/bash
SPOOL=”/home/stampepdf/spool”;
INPUT=$(basename $1);
chmod 666 “$SPOOL/$INPUT”;

Lo script è sicuramente migliorabile, andrebbe fatto un migliore controllo sull’input in modo da evitare di potergli passare come parametro qualcosa tipo “../../../etc/shadow” (anche se, in questo caso specifico la cosa non avrebbe molto successo) nei commenti mi hanno suggerito una piccola modifica (già integrata nel post) che aumenta decisamente il livello di sicurezza controllando meglio l’input.

Questo script va lanciato prima del programma di elaborazione vero e proprio, in modo da impostare sullo spool file i permessi necessari a poterci lavorare con l’utente stampepdf.

Configurazione della stampante

La nuova configurazione della stampante, a questo punto, diventa:

[stampante]
printing = BSD
comment = Descrizione stampante
path = /home/stampepdf/spool
read only = No
guest ok = Yes
printable = Yes
use client driver = Yes
print command = /home/stampepdf/spool.sh “%s”;
sudo -u stampepdf /home/stampepdf/scripts/elabora.sh “%s” “%D\%U”;
valid users = @”Domain Users”

Dal punto di vista del client Windows, è sufficiente collegarla e utilizzare un qualsiasi driver Postscript. Io di solito scelgo il driver postscript una qualunque stampante della famiglia HP Color Laserjet.

Cosa succede quando si lancia una stampa?

In questa situazione, quando un utente Windows lancia una stampa, succede che:

• Samba crea uno spool file in /home/stampepdf/spool appartenente all’utente AD che ha lanciato la stampa, con permessi 600
• Lo script spool.sh (che viene lanciato da Samba con lo stesso utente AD) cambia i permessi dello spool file appena creato in 666
• Lo script scripts/elabora.sh (lanciato attraverso sudo con l’utente stampepdf) prende in consegna lo spool file (su cui adesso ha anche permessi di scrittura) e ne fa ciò che meglio crede

Nel mio caso, alla fine delle elaborazioni, viene creato un file PDF in /home/stampepdf/stampe (a sua volta condivisa sempre attraverso Samba).

Una configurazione flessibile

La configurazione è abbastanza flessibile: si possono creare in modo semplice tutte le stampanti desiderate (mettendo gli script in /home/stampepdf/scripts) e, volendo, differenziare le cartelle di destinazione delle eleborazioni. Queste operazioni non richiedono ulteriori modifiche al file di configurazione di sudo, ma solo la creazione degli script per le elaborazioni e la (poco più che copia della) configurazione di Samba per stampanti e cartelle condivise. Bene!

Miglioramenti e possibili problemi

A occhio vedo tre punti in cui la sicurezza potrebbe essere un problema:

• permessi di /home/stampepdf/spool impostati a 777
• script /home/stampepdf/spool.sh decisamente migliorabile nel controllo dell’input
• sudo configurato per eseguire qualsiasi script /home/stampepdf/scripts/*.sh come utente stampepdf

Tra le funzionalità migliorabili, invece, c’è sicuramente l’installazione dei driver sul server: renderebbe l’installazione della stampante in ambiente Windows molto più rapida.