Permesso negato di rimontare tmp per exec

Sto facendo Fedora Linux su MediaTemple usando la loro scatola Linux virtuale. Praticamente un'installazione pulita (Linux ************ 2.6.18-028stab089.1 # 1 SMP gio apr 14 13:46:04 MSD 2011 x86_64 x86_64 x86_64 GNU / Linux).

Sto provando a fare alcune installazioni di Pear e bisogno di /tmp di essere rimontato con l'opzione exec . Nessun problema, giusto? Quindi sto funzionando come root e sto solo per andare:

  • Come posso trovare una parola ricorsivamente in tutti i file e tutte le directory
  • Iptables Problema di inoltro
  • Installazione di zPanel su CentOS 5.3
  • Perché ho potuto eliminare un file proprietario di root nella mia home directory senza essere root?
  • Catra recursiva assoluta senza directory padre?
  • Arresti cron dall'invio di posta a root per un process specifico
  • [root@host ~]# mount -o remount,exec /tmp
    mount: permission denied
    [root@host ~]#

    Beh, questo è piuttosto inaspettato. Supporto di MediaTemple non fornisce alcuna assistenza per questo – non è nella SLA. Dato che si tratta di una bella impostazione di vaniglia, forse qualcuno là fuori ha un'idea di cosa c'è di sbagliato qui?

    EDIT:

    Ecco alcune informazioni aggiuntive. Il mount esecuzione mostra questo:
    [root@host ~]# mount
    /dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
    /dev/simfs on /tmp type simfs (rw,noexec,relatime,usrquota,grpquota)
    /dev/simfs on /var/tmp type simfs (rw,noexec,relatime,usrquota,grpquota)
    proc on /proc type proc (rw,relatime)
    sysfs on /sys type sysfs (rw,relatime)
    none on /dev type tmpfs (rw,relatime)
    none on /dev/pts type devpts (rw,relatime)
    none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
    [root@host ~]#

    Il contenuto di /etc/fstab è:

    none /dev/pts devpts rw 0 0

    Successivamente ho provato ad aggiungere questa row a /etc/fstab :

    /dev/simfs /tmp simfs rw,exec,relatime,usrquota,grpquota 0 0

    Quindi eseguire mount /tmp risultati in:

    mount: unknown filesystem type 'simfs'

    Sono un po 'confuso di come è elencato il simfs quando si esegue il mount, ma quando lo si aggiunge a /etc/fstab non viene riconosciuto. Tuttavia, questo non sembra risolvere il mio problema, quindi sono ancora bloccato. Qualche idea?

    UPDATE 6/25/11

    @jamiers ha trovato una soluzione che MediaTemple ha inviato (vedi sotto). Tuttavia, ora mi chiedo l'aspetto più fondamentale di questo problema. Perché non è ansible ripristinare tmp con diverse opzioni in un ambiente virtuale? Da quello che posso sapere, non c'è nulla di intrinsecamente restrittivo in un ambiente virtuale che ti impedisca di fare qualcosa di simile. Qualcuno ha un'idea perché questo sia il caso?

  • Fedora 15 PHP exec () non funziona
  • wkhtmltopdf chiamata dai risultati di exec PHP nel codice di output 127 fallimento
  • Come configurare SSHd per consentire un singolo command, senza dare accesso completo all'utente?
  • exec sudo e / o submit un segnale a un bambino
  • 4 Solutions collect form web for “Permesso negato di rimontare tmp per exec”

    Ho avuto la stessa difficoltà durante l'installazione di PHP APC. Ho seguito le istruzioni in fondo alla guida: https://kb.mediatemple.net/questions/1987/Noexec+and+%7B47%7Dtmp+Troubleshooting#ve sulla creazione di un ambiente chrooted.

    Spero che questo ti aiuti!

    Tieni presente che stai eseguendo il kernel di MediaTemple (e tu non puoi cambiarlo). Può permettere o negare qualunque cosa voglia. Potrebbe essere necessario la fonte al proprio kernel per capirlo. Forse è una limitazione del file system simfs?

    Per montare tmp senza noexec è necessario rimontarlo dal nodo Hardware.

    Per ulteriori dettagli fare riferimento alla seguente documentazione.

    http://download.swsoft.com/virtuozzo/virtuozzo4.0/docs/en/lin/VzLinuxUG/18548.htm

    Preambolo

    poiché non posso commentare, illudere una risposta. le persone devono veramente fare la loro ricerca su openVZ (tra le altre tecnologie ..) prima di pubblicare …

    mi rendo conto che questa è stata una domanda da qualche anno fa, ma ho intenzione di disambiguare le bugie su OpenVZ / Virtuozzo e la disinformazione sulla virtualizzazione del sistema operativo ancora propagata oggi

    OpenVZ

    openVZ è un grande pezzo di tecnologia, che può essere utilizzato per una pletora di usi. ci sono molti usi per la virtualizzazione del livello di sistema operativo e molte persone rientrano nella categoria di bisogno di questo livello di simulazione …

    il suo come un Chroot sugli steroidi, ma con la possibilità di limitare le tabelle dei processi e l'utilizzo di hardware separato, a sua volta consentendo sisthemes fluidi funzionali all'interno di sisthemes operativi: ma con uno strato aumentato di sicurezza aggiuntiva e privacy o isolamento, pur consentendo l'accesso alla radice.

    purtroppo, le stesse menzogne ​​si diffondono attorno alla function Chroot … ognuno ti dirà di utilizzare la virtualizzazione e che non è una funzionalità di sicurezza. la maggior parte delle volte, questo non è del tutto vero, le accuse di insicurezza sono completamente false, poiché Chroot è direttamente integrato in una varietà di software popolari, di solito come una potente funzionalità di sicurezza e di isolamento (se utilizzata correttamente )

    una nota importnte è che non tutti gli amministratori hanno il livello di conoscenza necessario per proteggere tutti i parametri del kernel necessari su un server dedicato o in una virtualizzazione completa del sistema.

    questo significa che la distribuzione di OpenVZ significa che i tuoi clienti avranno molta superficie di attacco per cercare di coprire e proteggere prima di distribuire le loro applicazioni. un buon host farà un buon lavoro per assicurare questi parametri, e a sua volta, questo è meglio per non solo tutti sul Nodo, o nel data center, ma per l'integer insieme …

    Perché non cambiare?

    "considerando di cambiare", come suggerisce Michael Hampton, per la virtualizzazione completa del sistema , a causa di "piccoli problemi sconosciuti" non è solo un eccesso di overkill completamente inutile. questo è il segno di uno che non comprende pienamente lo scopo previsto. la completa simulazione del sistema include tutto, come i bios e gli interrupt hardware,

    questo significa che si ha less over-head quando si utilizza OpenVZ e quindi, in correlazione diretta a ciò che conclude la prova (i parametri di riferimento), ciò in genere determinerà una macchina virtuale più veloce, in particolare per chi ha un livello di comprensione less * nix e per non parlare di più alti livelli di sicurezza .. (supporre che each utente con una macchina virtuale capisca la sicurezza del kernel e che la patch personalizzata sia incredula)

    la conversione in una nuova tecnologia sarà sempre complicata e le tecnologie emergenti nel mondo open source stanno continuando a prendere tempo per essere perfezionati.

    Sto ora chiedendo l'aspetto più fondamentale di questo problema. Perché non è ansible ripristinare tmp con diverse opzioni in un ambiente virtuale?

    Così che cosa è il problema?

    con quello che ha detto e per rispondere alla tua domanda sui più moderni kernel OpenVZ in questi giorni, il problema è che i moduli plug-in dei kernel sembrano essere "mancanti", soprattutto nei comandi che dipendono direttamente da essi. ma sono ancora lì .

    la spiegazione è semplice, in quanto openVZ ha simulato il sistema operativo e non il kernel. dare l'accesso degli ospiti alle impostazioni correlate all'hardware sarebbe insicura. non si ottiene l'accesso diretto a hardware, dispositivi o sisthemes di file.

    questo può sembrare ingombrante, ma non è (una volta che il tuo arriva) e il traffico tra la sicurezza per i nuovi utenti e gli utenti esperti che devono capire come lavorare intorno (che un utente esperto dovrebbe sapere come fare comunque) , è sinceramente un modesto. su una macchina dedicata veramente sicura o KVM, si desidera implementare molti dei titoli a livello del kernel esistenti in un contenitore comunque

    infine, simfs è un dispositivo di sistema di file simulato per l'utilizzo con openVZ e non viene riconosciuto dal command file di mount (AFAIK).

    E come faccio a risolvere questo problema?

    non è sicuro se questo è il caso per te, ma dovrebbe essere risolvibile nella maggior parte delle versioni più recenti del kernel semplicemente emettere

    mount --bind -o defaults,exec /tmp /tmp

    e nella versione del kernel uno dei miei nodes host utilizzati, ho semplicemente lasciato cadere / dev / simfs all'interno di fstab, e mount -a funziona come previsto …

    esempio: none /tmp simfs defaults,exec 0 0

    Spero che questo aiuti qualcuno.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.