Newsgroup: it.comp.os.linux.development
Titolo: [Webserver] Consigli su implementazione e uso di Thread con  setgid/setuid

Salve a tutti,
è il mio primo post qui:)
Sto sviluppando un piccolo webserver da usare in sostituzione di
Apache sul mio server, questo perché ho la necessità di avere i vari
virtual host agganciati a specifiche limitazioni (principalmente
eseguiti con uno specifico user/group)
Attualmente uso l'mpm itk di apache che funziona abbastanza bene ma è
tremendamente pesante!
Ho già iniziato lo sviluppo del webserver, ho buttato le basi, ovvero
parsing del parametri, switching dell'utente sul processo principale,
sganciamento dalla sessione e caricamento file di configurazione
(ancora il parsing del file xml non l'ho implementato).
Ho letto sul documento della redhat riguardante l'implementazione dei
thread che uno dei problemi che la NPTL doveva "risolvere" era lo
switch utente sull'intero processo quando si usava setuid e setgid e
questa cosa per me sarebbe una mezza tragedia ... potrei aggirare la
cosa ma è gran casino!!!
Volevo chiedervi quindi se effettivamente setuid e setgid cambiano
queste informazioni solo per il thread cui vengono eseguiti o
retroattivamente li cambiano per tutti i thread di quel processo (non
di altri fork comunque, no?)
Questo per me è necessario perché il server funzionerà cosi (almeno
nella mia testa):
* Parte il server
* Analizza la configurazione (Legge i paramertri di default, legge le
tipologie di connessione con relativa configurazione, legge le socket
da bindare legate al tipo di connessione da gestire [http, pop3, imap
e cosi via {per adesso l'unico gestore sarà http}], legge la
configurazione dei moduli legati al tipo di connessione, legge la
configurazione degli esecutori delle richieste [ergo utenti/gruppi,
limitazioni di banda/traffico, limitazioni su numero di richieste e
altri parametri ancora, moduli da abilitare])
* Avvia N thread in base al numero di esecutori delle richieste (sono
questi i thread che leggono dal disco)
* Avvia M thread per i gestori del tipo della connessione (2 smtp, un
pop3, un imap e un http per esempio) a cui passa l'elenco delle pipe
inizializzate dai thread per comunicare in base ad i legami definiti
nella configurazione che poi switchano sull'utente/gruppo usato dal
server
* Avvia L thread in base al numero di socket da bindare (la 25, la 26
per l'smpt, la 110 per l'imap, la 143 per l'imap e cosi via) e passa,
in base ad i legami definiti nella configurazione, l'elenco delle pipe
avviate dai gestori per la comunicazione e poi i thread switchano
sull'utente/gruppo usato dal server
* Switcha l'utente del fork principale per gestire i segnali
Alternativamente invece che avviare N thread dovrei avviare N fork ...
ovviamente per gestire l'esecuzione asincrona finale andrei comunque
ad usare dei thread: appena mi arriva una richiesta alla socket questa
avvia un thread, accetta la connessione e si mette in comunicazione
con il gestore facendo da ponte [nel caso di connessioni crittografate
prima decritta] ... il gestore riceve la richiesta di una nuova
connessione quindi apre un thread, gli passa la pipe e fa analizzare
al thread gli header della connessione che a sua volta decide a quale
esecutore deve passare il tutto e si mette in comunicazione su una
pipe per far startare l'esecutore ad hoc al thread/fork specializzato.
Lo so, è un processo un po incasinato, però credo sia l'unico modo
flessibile per gestire la cosa ... o è una cosa assurda?
(se notate ORRORI di italiano avvisatemi che riposto il testo ... sto
di fretta :))

 fretta :))
Saluti   Manlio Perillo

 di altri fork comunque, no?)
Non ci metterei le mani sul fuoco, ma credo che setuid e compagnia
agiscano su tutti thread del processo.
Questo deriva direttamente dal fatto che setuid agisce su un processo
intero e che con NTPL i thread sono tutti in un unico processo.
Per il resto, causa fretta, ho letto molto velocemente il tuo post
(saltandone una buona parte, a dire la verita').
Ora io non sono un esperto di sicurezza, pero' non mi sembra una
grande mossa limitare i privilegi di alcuni thread e poi avere i
thread che condividono la stessa area di memoria. Credo che in questo
caso, se non si vuol cambiare approccio, sia meglio utilizzare i
processi.
Saluti,
The Librarian

 The Librarian
grazie anche a te!

 [...]
Manlio Perillo

 preempitiva) invece la cosa non è possibile
si però si possono sincronizzare i thread
Vorrei evitare l'uso eccessivo di fork per non mangiarmi il sistema

 Vorrei evitare l'uso eccessivo di fork per non mangiarmi il sistema
Ti serve almeno un processo per utente, ed un processo Apache prende 
abbastanza risorse.
Manlio Perillo

 abbastanza risorse.
si ma un processo per utente lo dovresti fare obbligatoriamente in
ogni caso (usi nginx, usi apache con mpm-itk o qualsiasi altra cosa
che giri sui sistemi posix) non c'è possibilità di evitarlo!

una piccola nota :)
Se dovessi usare nginx per dare un servizio tipo quello che do per
adesso (spazio web limitato tramite quota su disco [quindi i file
devono essere di propietà dell'utente anche quelli che creano
eventuali script di qualsiasi linguaggio], php [voglio attivare anche
python e ruby se per apache ci sono i moduli], mysql, e qualche altra
cosa) dovrei avere nginx, un istanza per utente, e fastcgi, un istanza
per utente, con la conseguenza che poi ogni istanza di nginx e di
fastcgi dovrebberò caricarsi in memoria i vari moduli che abilito.
Se poi a questo ci aggiungi che dovrei usare un reverse proxy
interfacciato con il mio database per prendere le richieste che
arrivano dall'80 e dalla 443 (anche su ip diversi) per poter rendere
"trasparente" la cosa andrei a creare un infrastruttura che è
sicuramente più complicata, e non poco, da gestire ed anche
probabilmente più pesante (per via dell'accoppiata fastcgi+nginx)

 python e ruby se per apache ci sono i moduli]
ruby non lo conosco, ma per python non serve nessun modulo

 sui sistemi posix) non c'è possibilità di evitarlo!
Appunto, quello che dicevo :).
Manlio Perillo