View Full Version : [iptables]identificazione processi
è possibile identificare i processi che richiedono l'accesso alla rete sulle catene di output?
per loggare qualcosa del tipo
il processo XX ha stabilito una connessione alle ZZ
ciao!
ho trovato il modulo owner che mi dà la possibilità di creare regole secondo il pid o l'owner.
però così posso bloccare processi che già conosco, io invece vorrei poter intercettare il tentativo di uscita e poterlo elaborare ancora prima che venga decisa la sua sorte
ciao!
ilsensine
13-06-2005, 14:16
...ovvero?
mmmmh che brutta domanda, ora chiami l'ambulanza e mi fai sbattere in manicomio :D
però speravo risponedessi :vicini: :D
allora:
supponiamo che io mi metta a lanciare ping.
ho le catene di output su -J DROP.
il mio sogno sarebbe appena il primo pacchetto cerca di uscire su OUTPUT venga spedito a un mio demone i dati relativi al processo che ha generato il pacchetto.
questo dovrebbe essere fattibile, vero? :mc:
il problema è che ora il mio bel pacchetto dovrebbe aspettare la risposta del demonuccio prima di uscire.
non so se si può fare...
ma per il momento lasciamo stare questa parte.
diciamo che per il momento mi limito a volere i dati sul processo che lo ha generato.
invece di mandarli a syslog o chi per lui dovrebbe spedirli al mio demone.
si può fare?
non ti chiedo la spiegazione di come si possa fare (suppongo non sia la cosa più veloce da spiegare), mi basterebbe qualche dritta....
grazie, ciao!
ilsensine
13-06-2005, 14:50
-j QUEUE
Puoi scrivere quindi il tuo bel programmino userspace che fa ciò che vuole con i pacchetti rigirati dal kernel, tramite le libipq:
http://www.google.it/search?hl=it&ie=ISO-8859-1&q=%22libipq%22&btnG=Cerca&meta=
oppure tramite i vari bind di questa libreria, come in Perl:
http://michael.toren.net/slides/ipqueue/slide005.html
Se invece ti interessa solo un log particolare, differente da syslog, usa -j ULOG.
sei mitico come al solito!!! :cincin:
però ho un problemino...
una volta presi i dati con ipq_get_packet se non sbaglio mi trovo con questa struttura
typedef struct ipq_packet_msg {
unsigned long packet_id; /* ID of queued packet */
unsigned long mark; /* Netfilter mark value */
long timestamp_sec; /* Packet arrival time (seconds) */
long timestamp_usec; /* Packet arrvial time (+useconds) */
unsigned int hook; /* Netfilter hook we rode in on */
char indev_name[IFNAMSIZ]; /* Name of incoming interface */
char outdev_name[IFNAMSIZ]; /* Name of outgoing interface */
unsigned short hw_protocol; /* Hardware protocol (network order) */
unsigned short hw_type; /* Hardware type */
unsigned char hw_addrlen; /* Hardware address length */
unsigned char hw_addr[8]; /* Hardware address */
size_t data_len; /* Length of packet data */
unsigned char payload[0]; /* Optional packet data */
} ipq_packet_msg_t;
e qui sono senza il mio bel pid :(
ci sono altri modi per andarselo a prendere?
grazie di nuovo, ciao!
ilsensine
13-06-2005, 16:22
Ah interessante :D
C'è una procedura indiretta (ma altamente inefficace) per i datagrammi tcp; forse c'è un modo più semplice, puoi provare a chiedere sulle loro ml.
C'è sempre l'alternativa di modificare i sorgenti di iptables, ovviamente :)
:D
i sorgenti di iptables li lascerei stare lì come sono :mc: :sofico:
ora vorrei solo un parere sull'idea prima di combinare troppi casini per nulla.
quello che vorrei realizzare è un firewall dinamico nello stile di quelli per windows.
prendi tutte le -m state NEW (la sintassi forse è sbagliata, ma credo che si capisca) e chiedi se accettarne l'uscita o l'entrata.
di conseguenza poi fai passare anche le related.
l'autenticazione dell'applicazione la lascerei con un md5 sull'eseguibile (metterlo anche sulle librerie sarebbe più sicuro, ma credo che diventi troppo pesante).
pensavo di strutturarlo con un demone che possa essere controllato solo da un gruppo di utenti (che ovviamente permetta di bloccare a un utente solo le sue uscite/entrate) e un client per utente che funzioni da interfaccia grafica.
ovviamente ha un senso solo su un desktop, ma aiutrebbe a prevenire problemi con applicazioni burlone che non fanno quello per cui si spacciano.
senza contare l'enorme facilità di configurazione (sarò stupido, ma arrivando da ZA ci ho messo quasi una settimana a capire come funzionava iptables).
che ne dici? varrebbe la pena di perderci un pò di tempo o è totalmente inutile/infattibile?
per ora sulla difficoltà sono ottimista, sull'utilità... bhò! attendo pareri :sofico:
ciao!
ilsensine
13-06-2005, 17:43
:D
i sorgenti di iptables li lascerei stare lì come sono :mc: :sofico:
Dai, è facile :D
quello che vorrei realizzare è un firewall dinamico nello stile di quelli per windows.
che è pericolosissimo, a meno che non fai qualcosa tipo:
l'autenticazione dell'applicazione la lascerei con un md5 sull'eseguibile
Buona idea, però...
(metterlo anche sulle librerie sarebbe più sicuro, ma credo che diventi troppo pesante).
Bravo, così un LD_PRELOAD ti frega.
che ne dici? varrebbe la pena di perderci un pò di tempo o è totalmente inutile/infattibile?
L'idea non è balzana e suppongo che qualcosa esista già, ma esce dal mio ambito.
Dovresti discuterne sulle mailing list di netfilter.
L'idea non è balzana e suppongo che qualcosa esista già, ma esce dal mio ambito.
Dovresti discuterne sulle mailing list di netfilter.
si, qualcosa esiste già per bsd se ben ricordo nella versione grafica si chiama xsystrace.
il porting per linux esiste, ma passa per una patch al kernel.
pessima cosa per ciò che è fatto per semplificare la vita.
Bravo, così un LD_PRELOAD ti frega.
mmmhh...
me la devo pensare meglio :D
se trovo una soluzione un salto su netfilter lo faccio, chissà che non esca qualcosa...
grazie di nuovo dell'attenzione!
ciao
ilsensine
13-06-2005, 20:09
Comunque ti do uno spunto che, almeno personalmente, potresti provare. Devi applicare un paio di patch al kernel (rigorosamente non testate in esecuzione):
La prima è alquanto dubbia, ma per quello che devi fare potrebbe andar bene. E' una modifica al layer socket che consente di tenere traccia del pid del creatore di un socket:
--- linux-2.6.11.4/net/socket.c.org 2005-06-13 20:51:53.000000000 +0200
+++ linux-2.6.11.4/net/socket.c 2005-06-13 20:39:11.000000000 +0200
@@ -404,6 +404,7 @@
file->f_mode = FMODE_READ | FMODE_WRITE;
file->f_flags = O_RDWR;
file->f_pos = 0;
+ file->f_owner.pid = get_current()->pid;
fd_install(fd, file);
}
La seconda è una patch al modulo ip_queue. Invece di inserire un campo pid nella struct ipq_packet_msg (sarebbe l'ideale, ma ti obbligherebbe a ricompilare anche iptables), "riciclo" il campo timestamp_usec per metterci dentro il pid:
--- linux-2.6.11.4/net/ipv4/netfilter/ip_queue.c.org 2005-06-13 20:56:37.000000000 +0200
+++ linux-2.6.11.4/net/ipv4/netfilter/ip_queue.c 2005-06-13 20:56:28.000000000 +0200
@@ -234,7 +234,9 @@
pmsg->packet_id = (unsigned long )entry;
pmsg->data_len = data_len;
pmsg->timestamp_sec = entry->skb->stamp.tv_sec;
- pmsg->timestamp_usec = entry->skb->stamp.tv_usec;
+// pmsg->timestamp_usec = entry->skb->stamp.tv_usec;
+ pmsg->timestamp_usec = entry->skb->sk->sk_socket->file ?
+ entry->skb->sk->sk_socket->file->f_owner.pid : 0;
pmsg->mark = entry->skb->nfmark;
pmsg->hook = entry->info->hook;
pmsg->hw_protocol = entry->skb->protocol;
Ho verificato che, almeno nella catena OUTPUT della tabella nat (quella che ti interessa, per i programmi locali), il risultato è corretto per un programma a singolo thread. Non ti consiglio di usare QUEUE per le altre catene; te lo sconsiglio vivamente per le catene di ingresso, qualsiasi esse siano (non ho verificato la patch su queste; se ti va bene, il campo ->file è nullo e non succede altro; se ti va male, c'è una "remota" possibilità di kernel oops :D)
mmmhh...
me la devo pensare meglio :D
Apri /proc/<pid>/maps, prendi i file indicati nei segmenti marcati "x" (eseguibile), e ne fai l'md5sum. I path sono assoluti, LD_PRELOAD è fregato.
ilsensine
13-06-2005, 20:16
il porting per linux esiste, ma passa per una patch al kernel.
Hai un link a questa patch?
pessima cosa per ciò che è fatto per semplificare la vita.
Hai il coltello dalla parte dei sorgenti, USALI diamine! :D
Apri /proc/<pid>/maps, prendi i file indicati nei segmenti marcati "x" (eseguibile), e ne fai l'md5sum. I path sono assoluti, LD_PRELOAD è fregato.
si, questo pomeriggio ci ho fatto qualche prova, mi era passato per la testa di leggere man proc e è stato molto istruttivo :)
la mia paura è che diventi un mattone a rilanciare gli md5 tutte le volte che apro il client di posta o firefox.
domani dopo l'esame (per cui avrei dovuto studiare oggi pomeriggio invece di girare per proc a fare cose a caso :sofico: ) provo a fare qualcosa.
per le catene in ingresso dovrebbe bastare chiedere l'autorizzazione nel momento in cui viene aperta una porta in ascolto. non so se si può fare (intendo intercettare ll'apertura della porta).
sto rileggendo di corsa gapil e nel frattempo guarderò sui sorgenti di netstat per cercare di farlo senza toccare niente (sempre che sia possibile, altrimenti si vagherò verso altre strade :D ).
la patch in versione 2.6 è qui:
http://www.citi.umich.edu/u/provos/systrace/systrace-linux-2.6.1-v1.5.diff
qui in versione 2.4
http://www.citi.umich.edu/u/provos/systrace/systrace-linux-2.4.24-v1.5.diff
comunque data la relase del kernel il port non sembra essere mantenuto.
dopo netstat lo guarderò (sperando di esserne all'altezza, il kernel lo ho toccato un paio di volte sui moduli di iptables e basta).
sei sempre mitico!!! :smack: :D
ciao!
ilsensine
13-06-2005, 21:23
si, questo pomeriggio ci ho fatto qualche prova, mi era passato per la la patch in versione 2.6 è qui:
http://www.citi.umich.edu/u/provos/systrace/systrace-linux-2.6.1-v1.5.diff
Stanne lontano. La mia patch è un hack a rischio di esplosione, ma almeno l'ho detto da subito :D
In quel link c'è almeno una race e alcune imprecisioni. E un semaforo bloccato dentro uno spinlock (un errore serio).
Stanne lontano. La mia patch è un hack a rischio di esplosione, ma almeno l'ho detto da subito :D
In quel link c'è almeno una race e alcune imprecisioni. E un semaforo bloccato dentro uno spinlock (un errore serio).
ok!
ho quasi rifinito gapil, tra un paio di giorni torno alla carica :cool:
Stanne lontano. La mia patch è un hack a rischio di esplosione, ma almeno l'ho detto da subito
In quel link c'è almeno una race e alcune imprecisioni. E un semaforo bloccato dentro uno spinlock (un errore serio).
una curiosità, come diavolo fai a passarti il codice così velocemente? mi umili terribilmente :sofico:
nel frattempo spero di aver trovato una soluzione al problema delle catene di input. nel caso ti posto la patch, spero di avere un tuo parere :vicini: :D
ti sto usando tantissimo, se spacco i gioielli di famiglia lasciami stare ;)
ciao!
gurutech
15-06-2005, 10:04
da qui (http://www.derkeiler.com/Mailing-Lists/Firewall-Wizards/2003-11/0059.html)
OWNER match v1.2.8-20030601 options:
[!] --uid-owner userid Match local uid
[!] --gid-owner groupid Match local gid
[!] --pid-owner processid Match local pid
[!] --sid-owner sessionid Match local sid
[!] --cmd-owner name Match local command name
non puoi semplicemente usare il cmd-owner ?
bel thread, sono interessato anche io, resto sintonizzato.
byez :D
ilsensine
15-06-2005, 12:05
non puoi semplicemente usare il cmd-owner ?
Credo volesse fare qualcosa di più complesso: prendere il pid di un processo che stava tentando una nuova connessione, e verificare runtime che il processo era "autorizzato" (controllando un hash dell'eseguibile e delle sue librerie).
Credo volesse fare qualcosa di più complesso: prendere il pid di un processo che stava tentando una nuova connessione, e verificare runtime che il processo era "autorizzato" (controllando un hash dell'eseguibile e delle sue librerie).
si, l'idea è questa.
il modulo lo vorrei utilizzare, ma con il pid per far passare su queque solo le new.
in questo modo eviterei ulteriore carico al sistema.
il processo chiede l'accesso alla rete e se è accettato metto in cima alla catena di filtraggio --pid-owner con accept.
l'ultimo elemento della catena deve rimanere queque, e il resto tutto droppato.
ho iniziato ora a fare qualche prova per vedere come funziona il tutto. vi tengo informati!
ciao!
PS: forse era meglio studiare per l'esame che guardare queste cose... ne avevo nettamente bisogno :D :sofico:
ilsensine
15-06-2005, 19:42
il processo chiede l'accesso alla rete e se è accettato metto in cima alla catena di filtraggio --pid-owner con accept.
...e quando il processo termina, chi pulisce?
...e quando il processo termina, chi pulisce?
pensavo di pulire le catene ogni tot minuti. ti sembra un'idea così schifosa?
non è il massimo della pulizia, ma far passare tutti i pacchetti per il mio programma non mi esalta molto.
tra il passaggio in user space, il mio demone e il ritorno indietro ho paura che alla fine pesi troppo.
che ne pensi?
pensandoci meglio la regola per i new deve essere all'inizio, altrimenti i processi con lo stesso pid e la stessa porta di uno vecchio lo lascia passare.
ciao!
ilsensine
15-06-2005, 20:45
pensavo di pulire le catene ogni tot minuti. ti sembra un'idea così schifosa?
No; è inoltre molto veloce vedere se un processo di un dato pid esiste ancora: basta inviargli un kill(pid, 0) -- nessun segnale viene inviato, ma se il pid non esiste la kill ritorna un errore.
tra il passaggio in user space, il mio demone e il ritorno indietro ho paura che alla fine pesi troppo.
che ne pensi?
Bè certo metterti a fare md5sum di librerie e programmi ogni volta...anche se sono in cache (de devi avere tanta memoria, vista la dimensione delle librerie che certi programmi usano) è un bel mattone.
Potresti "rilassare" i requisiti; ovvero se l'oggetto da testare è rwx--x--x root.root, lo consideri "affidabile".
pensandoci meglio la regola per i new deve essere all'inizio, altrimenti i processi con lo stesso pid e la stessa porta di uno vecchio lo lascia passare.
Basta che metti all'inizio la solita regola su -m state --state ESTABLISHED,RELATED.
Per inserire una regola a partire dalla seconda (o ennesima) posizione, puoi usare -I (invece di -A), ma se usi -m state potresti considerarlo superfluo.
secondo voi far accettare al demone solo connessioni da 127.0.0.1 è corretto?
con quell'inidirizzo posso essere certo che mi stia tornando indietro dall'interfaccia di loopback o esiste un modo per controllarlo meglio?
intedo una sorta di controllo sull'interfaccia di entrata.
ciao!
aaaaaaaaaaaaaaaaaaaaaah!
ho sviluppato parte del demone dopo aver riletto tutto il possibile.
ho lasciato una bellissima funzioncina che doveva prendere il pid in sospeso. ora ho provato a svilupparla e.......
aaaaaaaaaaaaaaaaaaaaaaah!!!
il pid è sempre 0 :eek: :cry:
che può ssere successo? ho anche riscritto un altro programmino (praticamente copiato da man), ma il risultato non cambia :(
#include <linux/netfilter.h>
#include <libipq/libipq.h>
#include <stdio.h>
#define BUFSIZE 2048
static void die(struct ipq_handle *h){
ipq_perror("passerr");
ipq_destroy_handle(h);
exit(1);
}
int main(){
int status;
unsigned char buf[BUFSIZE];
struct ipq_handle *h;
h = ipq_create_handle(0,PF_INET);
if(h == NULL){
die(h);
}
status = ipq_set_mode(h,IPQ_COPY_META,0);
if(status < 0){
die(h);
}
while(1){
status = ipq_read(h,buf,BUFSIZE,0);
if(status < 0){
die(h);
}
switch(ipq_message_type(buf)){
case NLMSG_ERROR:
fprintf(stderr,"Recived error: %d\n",ipq_get_msgerr(buf));
break;
case IPQM_PACKET:{
ipq_packet_msg_t *m = ipq_get_packet(buf);
fprintf(stderr,"pid: %ld , %u \n" ,m->timestamp_usec, m->packet_id);
status = ipq_set_verdict(h,m->packet_id,NF_ACCEPT,0,NULL);
if(status < 0){
die(h);
}
break;
}
default:
fprintf(stderr,"Unknown message type\n");
break;
}
}
return 0;
}
help! :mc:
mi correggo, stampa zero come intero, ma il campo sembra essere NULL
ciao!
mi correggo, stampa zero come intero, ma il campo sembra essere NULL
ciao!
mi ricorreggo da solo. sembra l'assegnazione della tua modifica al kernel.
l'espressione risulta falsa e allora ci piazza zero.
cosa è quell'affare che controlli? :eek:
ciao!
ilsensine
22-06-2005, 11:35
Puoi mettere una
printk("pid: %d\n", pmsg->timestamp_usec);
nella ip_queue.c, dopo l'assegnazione? (così dmesg dovrebbe stamparti quello che trova)
Quale regola di iptables usi per mandare un queue i pacchetti?
pid: 6390
no
pid: 0
si
pid: 6390
no
pid: 0
si
pid: 6390
no
pid: 0
si
pid: 6390
no
pid: 0
si
pid: 6390
no
pid: 0
si
pid: 6390
no
pid: 0
if(entry->skb->sk->sk_socket->file)
printk("si\n");
else
printk("no\n");
pmsg->timestamp_usec = entry->skb->sk->sk_socket->file ?
entry->skb->sk->sk_socket->file->f_owner.pid : 0;
printk("pid: %d\n", pmsg->timestamp_usec);
:eek: uno si e uno no... uno esiste e uno no....
il punto è che non trovo nemmeno la definizione di sk :D
ciao
ho sistemato il programmino, ora anche lui trova un pid valido e uno zero....
pid: 6450
pid: 0
pid: 6451
pid: 0
pid: 6451
pid: 0
pid: 6452
pid: 0
pid: 6452
pid: 0
ti dirò di più! :D
se lancio due ping insieme (la regola è sugli icmp) ho:
pid: 6480
pid: 6481
pid: 0
pid: 6480
pid: 6481
pid: 0
due validi e uno no! :eek:
per ora metto un controllo che mi escluda lo zero, intanto non credo che sia un pid valido.
ciao!
ah, la ho provata sull'input!
il sistema si freeza :D
avevavi ragione.
però sto continuando con l'idea di netstat per l'input, non mi sembra malissimo.
ciao
ilsensine
22-06-2005, 13:20
ah, la ho provata sull'input!
il sistema si freeza :D
avevavi ragione.
però sto continuando con l'idea di netstat per l'input, non mi sembra malissimo.
ciao
Ti ho detto di usarla solo con -t nat e catena di OUTPUT ;)
In altre catene puoi andare da un crash ( :D ) a un "pid 0".
ok, ultima domandona!
quando avevi detto che aggiungedno un record alla struttura avrei dovuto ricompilare iptables hai sottointeso anche delle modifiche?
o posso semplicemente cambiare la dichiarazione e ricompilarmi il mio bel iptables?
ciao!
ilsensine
22-06-2005, 18:04
Dipende se i sorgenti di iptables definiscono per conto proprio quella struttura, oppure usano gli header del kernel. Non ho controllato.
controllerò con il mio solito metodo barbaro :D
grazie di nuovo
ciao!
non sono scomparso! :)
volevo un parere. prima che riceva la prima connessione di un client (quello che si occupa di chiedere all'utente se vuole accettare o no le connessioni) come mi dovrei comportare?
rifiuto tutto?
accetto tutto?
accetto solo quello che ha i privilegi di amministrazione?
ciao!
ilsensine
21-07-2005, 08:34
Non è che sei molto chiaro...
Per "client" intendi "programma locale che vuole connettersi fuori"?
Non è che sei molto chiaro...
:cool:
ho un demone che gira che prende i pacchetti nuovi con ipq, confronta gli md5 attuali con quelli del suo database (ho usato il berkeley).
quando non li trova prende i dati, e fa una richiesta all'utente.
la comunicazione tra il demone e l'utente ho pensato di realizzarla con dei socket locali (non so se si dice così, cmq ho usato AF_LOCAL).
in pratica il demone quando trova md5 errati o non ha record sul programma manda le informazioni al client dell'utente che ha avviato il programma che si crea la sua finestrella e chiede all'utente.
la prima soluzione che mi sono pensato per evitare di intercettare pacchetti prima di avere qualcuno che mi dica che fare mi sono pensato di aspettare prima una connessione.
a parte che questo lascia la parte di avvio quasi completamente scoperta (qui bisogna mettere delle regole di default), ma mi impedisce anche di avere più connessioni da più client dato che una fork mi sdoppierebbe anche la parte di creazione dell'handler delle ipq.
c'è anche da dire che difficilemnte troveremo un pc che ha più utenti collegati, ma dato che a livello di righe di codice costerebbe relativamente poco mi sarebbe piaciuto implementarlo.
il programma quindi una volta avviato dovrebbe avere un comportamento di default in attesa della prima connessione del client.
potrei lasciarlo configurare all'utente, ma allora l'obbiettivo del programma si vanifica (dovrebbe comunque mettere le mani a iptables per avere delle regole di default).
potrei accettare trutto quello che viene da root...
potrei accettare le estabilished e le related, ma vanificherei il filtro sull'output...
spero di essere stato più chiaro :sofico:
cmq ora vado in vacanza!
continuerò il 9 agosto al ritorno :cool:
ciao
ilsensine
21-07-2005, 15:15
Continua a non essere chiarissimo, comunque vediamo...
la comunicazione tra il demone e l'utente ho pensato di realizzarla con dei socket locali (non so se si dice così, cmq ho usato AF_LOCAL).
Sì sono unix domain socket.
Come "autentichi" l'applicazione utente che si connette al socket per dialogare con il demone?
la prima soluzione che mi sono pensato per evitare di intercettare pacchetti prima di avere qualcuno che mi dica che fare mi sono pensato di aspettare prima una connessione.
Rileggiti questa frase, concluderai che effettivamente è meglio che continui dopo le vananze :D
a parte che questo lascia la parte di avvio quasi completamente scoperta (qui bisogna mettere delle regole di default), ma mi impedisce anche di avere più connessioni da più client dato che una fork mi sdoppierebbe anche la parte di creazione dell'handler delle ipq.
Anche qui ho bisogno degli eségeti (o esegèti?) di Nostradamus.
...cosa dicevi riguardo al fork?
c'è anche da dire che difficilemnte troveremo un pc che ha più utenti collegati, ma dato che a livello di righe di codice costerebbe relativamente poco mi sarebbe piaciuto implementarlo.
il programma quindi una volta avviato dovrebbe avere un comportamento di default in attesa della prima connessione del client.
potrei lasciarlo configurare all'utente, ma allora l'obbiettivo del programma si vanifica (dovrebbe comunque mettere le mani a iptables per avere delle regole di default).
potrei accettare trutto quello che viene da root...
potrei accettare le estabilished e le related, ma vanificherei il filtro sull'output...
Le connessioni NEW provenienti dall'utente root dovresti bloccarle sempre, e loggare l'evento. A meno che non hai un lammah in casa che naviga come root.
Le connessioni established,related puoi farle sempre passare tramite iptables. Non c'è motivo di riverificarle ogni volta, e renderebbe la rete lentissima.
Puoi adottare la soluzione più semplice: se non ci sono client connessi, _quindi_ non ci sono utenti loggati, blocchi tutto.
cmq ora vado in vacanza!
continuerò il 9 agosto al ritorno :cool:
Un consiglio: se quanluno ti chiede indicazioni per strada, rispondi che non sai niente :D
sono tornato!
ho speso un pacco di tempo a rifattorizzare il codice, ora è diventato di dimensioni irrisorie, e si legge che è un piacere :D
Puoi adottare la soluzione più semplice: se non ci sono client connessi, _quindi_ non ci sono utenti loggati, blocchi tutto.
ok. per la verità io lascerei l'handler a lavorare filtrando tutte le connessioni in base a quello che è memorizzato nel db delle applicaizoni valide. ti sembra un'idizozia?
e ora l'ultimo problema (in realtà la parte del kernel la ho lasciata un pochino indietro... :sofico: ):
si collega l'utente pippo al mio demone.
secondo te dovrei aspettare anche altre connessioni?
complica di brutto la gestione del codice (e del database) e non so che uso se ne potrebbe fare.....
su un desktop dubito ci saranno mai due utenti collegati insieme.
che ne dici?
ciao!
ilsensine
07-10-2005, 15:01
Scusa, ma dopo tre mesi che vuoi che mi ricordi di quello che stavi facendo? :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.