Newsgroup: it.comp.os.linux.sys
Titolo: Comandi root da chroot

Ciao a tutti,
tramite un pannello di controllo che stò facendo sotto Apache in chroot
avrei bisogno di eseguire comandi root (naturalmente esterni dalla chroot).
Conoscete qualche metodo? Oppure devo rassegnarmi a togliere Apache dalla chroot?
Grazie a tutti.
Ettore

 Ettore
sudo non ti va bene ?

 Conoscete qualche metodo? Oppure devo rassegnarmi a togliere Apache dalla chroot?
si, copia il file binario ;)
--
Ranger!



Se hai voglia di buttare il tuo tempo fai pure...
Indipendentemente da chroot, non puoi eseguire processi con i permessi di
root da apache, visto che "in ogni caso" i processi avranno l'id di
apache, ma questo lo dovresti sapere visto che vuoi fare un pannello di
controllo...
Quindi devi utilizzare un webserver che gira con i permessi di root o in
alternativa (sconsigliata) creare un applicazione "server" ed una "client"
che comuinicano via socket con un protocollo che dovrai definire.
la soluzione più intelligente a mio avviso e che ti permette di avere una
gestione semplificata di password e supporto SSL per le sessioni è di
scrivere un modulo per webmin (
www.webmin.com
) che risolve appunto il tuo
problema.
NB: i moduli di webmin sono ovviamente in perl ma è possibile farli anche
in php modificando il server stesso per utilizzare PHP come cgi.
Và da se.. che ogni script dovrà iniziare con: #!/usr/bin/php 
Se serve qualche dritta..

 che comuinicano via socket con un protocollo che dovrai definire.
L'alternativa è sconsigliata ??
Quello che è sconsigliato è far girare apache come root, in qualsiasi luogo
ed in qualsiasi tempo, con qualsiasi condizione metereologica e
metereopatica.
Forse farlo girare come root è più comodo, su questo concordo.
Ma ciò non toglie che sia _SEMPRE_ e _SOLO_ una porcata e che l'altra
soluzione da te citata sia più lunga da fare, ma ben più pulita e sicura.
Max

Netstrike ha scritto:

forse dico una fesseria... montare le directory via loopback? ho fatto 
una cosa simile con degli utenti virtuali sotto proftpd che dovevano 
vedere altre directory sotto la loro ftproot
-- 
There's a meme infecting the Internet: the browser wars are back.
http://www.spreadfirefox.com/?q=affiliates&amp;id=4123&amp;t=63



Vedi che stiamo dicendo la stessa cosa probabilmente..
Io parlo di un applicazione "server" nel senso di un demone che sta li ad
aspettare una connessione sull'interfaccia di loop su una porta N non di
far girare apache come root (ovviamente).
E questa è decisamente la via più lunga visto che devi scriverti da zero
il server ed anche il client.
Un modulo webmin lo fai in 10 minuti e sfrutti un server nato e concepito
proprio allo scopo di amministrare sistemi *.nix.

 Quindi devi utilizzare un webserver che gira con i permessi di root
Mai dare un consiglio del genere, suvvia...:)
/me once upon a time there was openssl-too-open...
P.S.
<SAN su linux>
Ma se mi scrivessi, piuttosto?
</SAN su linux>
-- 
No more tradition's chains shall bind us;
Arise, ye slaves! No more in thrall!
The Earth shall stand on new foundations;
We have been naught - We shall be All!

 vedere altre directory sotto la loro ftproot
Scusatemi, eh, ma continuo a non capire il perchè di tutto ciò.
Se si sceglie di chrootare, perchè ostinarsi pervicacemente
a fare dei buchi in quella gabbia?


 /me once upon a time there was openssl-too-open...
Webmin come lo definiresti?
lavorando via http/s io lo definisco un webserver poi lo possiamo chiamare
in vari modi ma la sostanza non cambia.

 Webmin come lo definiresti?
"Something to definitively avoid" può andare, direi.
Ma probabimente è solo una mia perversione, che dire.


 a fare dei buchi in quella gabbia?
Ma appunto, "te lo appoggio".
Ci sono un fottio di modi per comunicare all'esterno.
raw sockets, tcp e perchè no un DB ??
Un DB all'esterno del chroot sarebbe accessibile via TCP.
Ci butti i dati dentro e li elabori dall'esterno.
Per carità, la sicurezza è una cosa filosofica.
Ma perchè chrootare quando poi devi fare troiate come metterci dentro il
mondo, nel chroot ?
Max

 mondo, nel chroot ?
La mia domanda era appunto per trovare un modo per non aprire buchi in
chroot...
Se devo aprire buchi tanto vale non mettere per niente in chroot.
Comunque credo di aver trovato una soluzione, non so quanto elegante
sia comunque:
Faccio uno scriptino in perl che mi apre una connessione ssh interna e
mi spara comandi all'ambiente root esterno.
Quindi dentro chroot ci sarebbero apache, ssh e perl.
Come la vedete?

 Quindi dentro chroot ci sarebbero apache, ssh e perl.
E quindi autenticazione su chiavi?
Lasciare la chiave privata di un accesso ssh (a root?) all'interno del 
chroot?
Folle.
Fai un sistema client/server, con un processo in chroot che contatta uno 
fuori chroot e gli delega l'esecuzione.
Se non vuoi tirarti dentro la gestione dei socket puoi banalmente 
leggere e scrivere su named pipe, se l'applicazione lo consente.
Occhio alla validazione.
-- 
cat: .signature: No such file or directory

 Come la vedete?
Premesso che sei liberissimo di fare e gestire i progetti che vuoi come
preferisci, come dicono a New York, "nonmenefregangazz".
Perň: esattamente come una DMZ, dalle chroot NON si deve uscire. PUNTO
Inoltre: un task NON sicuro come apache che va di ssh sull'host come ROOT č
altrettanto una boiata in termini.
Fai una directory nel chroot, fai in modo che apache ci scriva dentro dei
files di teso con quello che deve fare (non comandi di shell, bensi roba da
parsare per essere sicuri che non faccia stonzate (per intenderci, non ci
deve essere scritto rm -rf / ).
Fai un demoncino in perl, in bash, in python, in ruby, in assembler..
insomma, come preferisci, che giri all'esterno del chroot, cerchi quella
directory per i files e se ne trova uno, parsa ed esegue.
Se proprio vuoi fare lo SBORONE usa dnotify/inotify per lanciare il
programma all'esterno solo quando quella directory varia il contenuto.
Detto questo fai come referisci (poi ti mando la fattura per la consulenza
:) )
Max

 Detto questo fai come referisci (poi ti mando la fattura per la consulenza
Hai perfettamente ragione ho pensato anche io la stessa cosa dopo aver
postato... e mi sono accorto della tremenda boiata che volevo fare...
Questa cosa del dnotify (che non conoscevo) mi piace assai.
Grazie mille!!!

 
be', la mia necessita' era piuttosto semplice: far vedere a degli utenti 
"amministratori" piů ftproot degli utenti "amministrati" (ovviamente con 
la possibilita' di cambiare le cose on the fly). per questo ho evitato 
di complicarmi l'esistenza (e poi quel sito ftp non e' pubblico, quindi...)
