Esecuzione di processi di avvio come utenti non privilegiati

Qual è il modo canonico per fare in modo che un processo di avvio cambi il suo ID utente ed esegua lo script come utente non privilegiato?

Ovviamente si può usare suo sudo, ma questo sembra confuso (e può generare linee di log inutili).

Con upstart v1.4, setuid e setgid sono supportati nativamente nel file di configurazione.

Chiedere sul canale #upstart su freenode, la versione ufficiale della questione è:

Una versione futura di Upstart avrà il supporto nativo per questo, ma per ora, puoi usare qualcosa come:

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

Che ne dici di usare start-stop-daemon?

exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd

Dal ricettario Upstart :

Il metodo raccomandato per i sistemi Debian e Ubuntu è usare l'utility helper start-stop-daemon. […] start-stop-daemonNon impone limiti PAM ("Pluggable Authentication Module") al processo che inizia.

Nota: start-stop-daemonnon supportato in RHEL.

Esistono diversi modi per farlo, tutti con una semantica leggermente diversa, in particolare per quanto riguarda l'appartenenza al gruppo:

• setuidgid ti inserirà nel gruppo specificato.

  • I daemontools originali setuidgidvi metterà solo in quel gruppo, in modo da non essere in grado di accedere ai file appartenenti ad altri gruppi sei un membro di.
  • Il setuidgidda daemontools-bis e setuidgiddal set di strumenti di gustare uno spuntino sia avere un -s(aka --supplementaryoptional) che vi metterà in quel gruppo, e anche mettere in tutti i gruppi supplementari per l'utente che si specifica.

• L'uso newgrpuna volta diventato l'utente meno privilegiato aggiungerà un singolo gruppo al tuo gruppo, ma crea anche una nuova sottostruttura, rendendo difficile l'uso all'interno degli script.

• start-stop-daemon preserva la tua appartenenza al gruppo e fa molto di più di un semplice setuid / setgid.

• chpst -u username:group1:group2:group3... commandnameti permetterà di specificare esattamente quali appartenenze ai gruppi adottare, ma (in Ubuntu ) viene fornito solo con il runitpacchetto, che è un'alternativa a upstart.

• su -c commandname usernameraccoglie tutte le appartenenze al gruppo del nome utente sudo -u username commandname, così come è , quindi sono probabilmente la strada per il minimo stupore.

Utilizzare setuidgiddal pacchetto daemontools.

Documentazione qui: http://cr.yp.to/daemontools/setuidgid.html

Su un'istanza di Ubuntu 10.10 su Amazon EC2, ho avuto più fortuna con il start-stop-daemoncomando.

Ho anche lottato con alcune delle altre stanze upstart . Sto chiamando un'applicazione Python con uno specifico virtualenve alcuni parametri per il mio programma eseguito.

Quello che segue è ciò che ha funzionato per me.

script
  export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/
  exec start-stop-daemon --start  --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 &
end script

Il PYTHONPATHè quello di ottenere alcuni pacchetti installati dalla sorgente al PITONE percorso del modulo quando questo lavoro viene eseguito upstart. Ho dovuto fare tutto in percorsi assoluti perché la chdirstanza non sembrava funzionare.

Stavo usando CentOS 6 e non riuscivo a far funzionare l'hacker consigliato (per Upstart 0.6.5), né il trucco "su" perché il numero di forchette coinvolte (4 credo) non è stato monitorato da "prevede fork" 'o' prevedono daemon '.

Alla fine l'ho appena fatto

chown user:group executable
chmod +s executable

(cioè impostare il bit setuid e cambiare la proprietà).

Potrebbe non essere il metodo più sicuro, ma per un progetto interno di ricerca e sviluppo, nel nostro caso non ha importanza.

C'è una terza possibilità a seconda di ciò che stai cercando di realizzare. Potrebbe essere possibile allentare i controlli di accesso sui file / dispositivi in ​​questione . Ciò può consentire a un utente non privilegiato di montare o accedere a elementi che normalmente non gli sarebbe permesso. Assicurati solo di non dare via le chiavi del regno nel processo.

È inoltre possibile modificare il timeout della cache della password sudo . Ma non lo consiglio a meno che la tua macchina non sia fisicamente sicura (cioè, ritieni che sia improbabile che un passante tenti di ottenere l'accesso sudo).

C'è una buona ragione per cui ci sono pochissimi modi per eseguire azioni privilegiate e che eseguono la registrazione inutile necessaria . Restrizioni allentate costituirebbero un pericolo per la sicurezza del tuo sistema e una mancanza di registrazione significherebbe che non c'è modo di sapere cosa è successo quando sei stato compromesso.

Se la dimensione dei file di registro è un problema, probabilmente qualcosa non va. Sudo genera solo una riga per utilizzo in condizioni normali.

In CentOS 6, upstart 0.6.5, il seguente è ciò che ha funzionato per me.

script

    exec su user_name << EOF
        exec /path/to/command [parameters...]
EOF

end script

o :

script

    exec su user_name << EOF
       ..... what you want to do ....
EOF

end script

Quando l'uso

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

il processo di lavoro non può essere fermato da initclt stop. Penso che il motivo sia:

1. the job forked and the main process is not tracked.
2. the main process changed its process group,because of `su -c`