Esiste un rischio per la sicurezza con l'aggiunta di una ** chiave pubblica di root * ai authorized_keys dell'utente locale (quindi root per accedere come utente in modo non interattivo?)

Sfondo:

Voglio provare i contenitori lxc non privilegiati e provare sul mio piccolo server web (che ospita da 2 a 4 utenti). Poiché il server è condiviso tra amici, abbiamo deciso di separare i nostri servizi dalla macchina utilizzando contenitori leggeri. Prevediamo che ogni utente eseguirà una serie di contenitori non privilegiati per ogni suo servizio con un'opzione, che i contenitori di servizi / lxc selezionati verranno avviati all'avvio del sistema.

In circostanze normali, si dovrebbe semplicemente usare setuid e setgid stanza per eseguire contenitori lxc nel contesto di ciascun utente. Sfortunatamente non funziona; Sospetto che abbia qualcosa a che fare con i requisiti subuid dei contenitori non privilegiati. Comandi come sudo -u <user> -- lxc-autostart o su -l <user> -c lxc-autostart non possono modificare le proprietà subuid dell'entità chiamante (che è root in caso di upstart).

Finora, l'unico modo per chiamare container non privilegiati da un altro account che ho trovato è tramite ssh <user>@localhost lxc-autostart .

La domanda riformulata

Posso inserire tale invocazione sullo script upstart, ma per farlo funzionare Devo generare un certificato pubblico per root e assicurarmi che <user> accetti la registrazione automatica da upstart ' root . È sicuro?

L'host è a 64 bit di Ubuntu 14.04; usa già ssh. Per quanto riguarda le migliori pratiche di Ubuntu, non esiste una password per root e root con .ssh/authorized_keys vuota.

No <user> con contenitori lxc automatici usa ecryptfs (A.K.A. home crittografata), poiché sarebbe comunque inutile su tale impostazione.