Più che di svelare chissà quale segreto, l’intento di questo post è di costituire un quasi memorandum per amministratori (e non solo).

Parliamo di scrittura, non necessariamente di condivisione della proprietà del file: pertanto sono esclusi gruppi più o meno esoterici, ACL o altri sistemi basati su privilegi su filesystem.

Ovviamente la soluzione residua è un’assegnazione di diritti amministrativi al processo di scrittura, e quindi una soluzione basata su sudoers.

Naturalmente occorre trovare una mediazione tra rispetto della sicurezza del resto del sistema e una certa flessibilità del meccanismo.

La sicurezza la imponiamo fissando nella lista comandi della regola sudoers il nome assoluto del particolare file di sistema su cui delegare il privilegio di scrittura.

La flessibilità del meccanismo la otteniamo considerando la sorgente dei dato non originante da altro argomento di un comando da attivare con sudo (vedi cp), ma invero dallo standard input del comando da attivare, implicando quindi un ulteriore processo di delega.

Per ragioni di opportunità e di semplicità di realizzazione in termini di sintassi sudoers la scelta del comando ricade su /usr/bin/tee.

Ponendo in /etc/sudoers la seguente:

utente ALL = (root) NOPASSWD: /usr/bin/tee /file/protetto

l’utente ordinario potrà modificare il file di sistema (protetto) assumendo temporaneamente i privilegi amministrativi; dovrà  quindi scrivere:

cat /file/sorgente | sudo '/usr/bin/tee /file/protetto' >/dev/null

Ovviamente la cosa potrà estendersi oltre il contesto locale con:

cat /file/sorgente/locale | ssh -t utente@host.remoto sudo /usr/bin/tee /file/protetto/su/host/remoto

dove opzione -t è fondamentale perché ssh possa lavorare in pipe eseguendo un sudo remotamente.

Speriamo di aver fornito un contributo per risolvere uno dei più  classici problemi di sicurezza di un sistema.