cerco auto
SALvE, hai necessità di liberarti di auto o furgone inutilizzati? Non esitare a chiamarmi,ritiro con passaggio immediato a mio carico.Chiedere di Antonio cell.324-7474742
Re: gruppi di default in debian jessie
On 13/12/2013 11:54, Gian Uberto Lauri wrote: Che so, infettare abbastanza macchine via rete, dispositivi rimovibili come le pennette USB e, perché no, il device audio (ci sono già malaware che usano gli ultrasuoni per comunicare a breve raggio) colpendo indiscriminatamente tutte le macchine possibili fintanto che se ne trova una con le caratteristiche che la fanno riconoscere come bersaglio principale. dico qualcosa solo su questo punto. Il virus che usava lo speaker per infettare qualsiasi macchina con qualsiasi sistema operativo era una bufala. A livello teorico (mi sembra che sia stato dimostrato dopo l'uscita della bufala) è possibile far comunicare due PC tramite speaker e usando suoni esterni alla fascia udibile da un essere umano, ma: 1) il PC, oltre che lo speaker deve essere dotato di microfono 2) entrambi i PC devono avere microfono e speaker "acceso" e "attivo" 3) il microfono deve essere "configurato" correttamente per non tagliare o introdurre rumori che rendano impossibile "interpretare" il messaggio spedito... e deve essere in grado di "ascoltare" le frequenze emesse 4) nella stanza non ci deve essere un rumore che si sovrappone alla frequenza usata 5) i PC non devono essere troppo lontani 6) i due PC devono essere preventivamente infettati dall'ipotetico virus che poi usa tale mezzo di comunicazione bastano queste considerazioni che ho scritto di getto per far capire che la probabilità di successo tende a zero. Anche perché se è vero il punto 6 perché dovrebbe l'attaccante sprecare così tante risorse e prendersi così tanti rischi per far comunicare due PC che ha già "conquistato"? Se il punto 6 non è vero, allora la trasmissione del messaggio non può avvenire. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Client di posta: http://www.mozilla.org/products/thunderbird GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ab6b5f.2050...@gmail.com
Re: gruppi di default in debian jessie
Federico Di Gregorio writes: > Il problema non è tanto sudo quanto il fatto di convincere un utente con > permessi amministrativi ad eseguire il cavallo di troia come se fosse un > comando normale. Non è così difficile come credi tu. > Il tuo esempio funziona anche con "su" (invece di sudo) > con la semplice differenza che il cavallo di troia aspetta il comando > su, falsifica il prompt, ti ruba la password, e via... Vero, ma con sudo è stateless e non interferisce con i comandi dell'utente, ne aggiunge qualcuno in più. Ed era un esempio del menga. Mi aspetto qualcosa di più raffinato dal vero attacco. > Questo è il motivo per cui se si accede al sistema con un utente > sudato L'utente sudato rischia la scossa, il sudore è una soluzione salina... :) > 2) Avere in PATH solo directory che non possano venire scritte dal > mondo Meno se ne hanno e meglio è. > 3) In qualsiasi caso, prima di fare ./ciccia/puccia/salva_il_mondo > controllare con molta attenzione che quel comando salvi DAVVERO il mondo > e non faccia altro. Quanti hanno le competenze per farlo? Come ho detto, questi sono attacchi che non credo sarà conveniente fare fintanto che non ci sarà una massa critica di utenti poco preparati. E comunque può capitare anche a quelli preparati di venire aggirati. -- /\ ___Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_ African word //--\| | \| | Integralista GNUslamicomeaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso...Debian" Warning: gnome-config-daemon considered more dangerous than GOTO -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21163.16434.222490.153...@mail.eng.it
OT - cerco CPU
Un saluto a tutti, Come da oggetto sono alla ricerca di una CPU usata (purchè non "sfiancata" da overclock) tipo Intel q6600 o q9550 Devono assolutamente supportare questa istruzione: Intel ® Virtualization Technology (VT-x) ‡ e se possibile anche quest'altra: Intel® Virtualization Technology for Directed I/O (VT-d) ‡ Ovviamente potete tranquillamente contattarmi in privato Felice -- decette 'o pappece vicin'a noce... ramm'o tiempo, ca te spertoso... -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ab3b06.2020...@infinito.it
Re: gruppi di default in debian jessie
On 13/12/2013 14:19, Gian Uberto Lauri wrote: > Piviul writes: > > Gian Uberto Lauri scrisse in data 13/12/2013 11:54: > > > Perché di default sudo fa il caching delle credenziali: con la > > > configurazione di default, per alcuni minuti sudo non chiede > > > nuovamente l'autenticazione (su -c non lo fa mai). > > sai che ho letto la tua mail 2 o 3 volte ma non sono riuscito a capire > > dove sia il problema di sudo? Ho capito che riguarda la cache ma poi... > > > [...] > > Provo ad indicartelo con una scala temporale con un esempio rozzo > senza ipotizzare come una cosa viene fatta. > > 1 - l'attaccante riesce a far eseguire il cavallo di troia. [snip] Il problema non è tanto sudo quanto il fatto di convincere un utente con permessi amministrativi ad eseguire il cavallo di troia come se fosse un comando normale. Il tuo esempio funziona anche con "su" (invece di sudo) con la semplice differenza che il cavallo di troia aspetta il comando su, falsifica il prompt, ti ruba la password, e via... Questo è il motivo per cui se si accede al sistema con un utente sudato o che farà su in una shell bisogna sempre: 1) NON avere "." in PATH 2) Avere in PATH solo directory che non possano venire scritte dal mondo 3) In qualsiasi caso, prima di fare ./ciccia/puccia/salva_il_mondo controllare con molta attenzione che quel comando salvi DAVVERO il mondo e non faccia altro. federico -- Federico Di Gregorio federico.digrego...@dndg.it Di Nunzio & Di Gregorio srl http://dndg.it E tu usa il prefisso corretto Re: non R:, questa è una ML seria. -- cosmos, su debian-italian -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ab2e16.5080...@dndg.it
Re: gruppi di default in debian jessie
Piviul writes: > Gian Uberto Lauri scrisse in data 13/12/2013 11:54: > > Perché di default sudo fa il caching delle credenziali: con la > > configurazione di default, per alcuni minuti sudo non chiede > > nuovamente l'autenticazione (su -c non lo fa mai). > sai che ho letto la tua mail 2 o 3 volte ma non sono riuscito a capire > dove sia il problema di sudo? Ho capito che riguarda la cache ma poi... > > [...] Provo ad indicartelo con una scala temporale con un esempio rozzo senza ipotizzare come una cosa viene fatta. 1 - l'attaccante riesce a far eseguire il cavallo di troia. 2 - il cavallo di troia piazza "l'imboscata" 3 - L'imboscata si pone in attesa, diciamo che riesce a prendere il controllo dello stdin e stdout della shell, ma non si mette a fare logging (per non creare tracce della sua presenza). Fa passare tutto l'input dell'utente e si preoccupa di non fare vedere all'utente quello che non deve vedere. 4 - periodicamente prova a lanciare - ad esempio - "sudo ls" e a vedere se ottiene una richiesta di prompt, nel qual caso manda un carattere di terminazione al sudo che ha lanciato e nasconde l'output all'utente; se invece si ha un risultato positivo grazie al fatto che l'utente ha usato sudo e le credenziali sono in cache, allora può "dare il via all'invasione" avendo la possibilità di agire con l'id 0:0 . Questo non è un attacco in grado di dare risultati immediati. Richiede molta pazienza ed un numero sufficientemente elevato di vittime (per ottenere in parallelo quello che è lungo ottenere in serie). Esattamente come stuxnet. Avendo a disposizione l'immensa base di untenti di sistemi Windows hanno lanciato l'attacco. Questo ha cominciato a diffondersi a destra ed a sinistra (usando exploit acquistati al mercato nero - a qanto pare) fintanto che un giorno, passando chissà quante macchine e chiavette USB, una copia di stuxnet -delle migliaia e migliaia attive - ha raggiunto una macchina bersaglio e ha fatto il suo dovere. > > fare un piccolo cavallo di troia > > che si metta in attesa del momento in cui vede che la cache delle > > credenziali sia attiva per poi iniettare codice malevolo sfruttando > > sudo e la configurazione 'utente ALL=(ALL)ALL'. > AFAIK la cache delle credenziali di sudo può > essere utilizzata soltanto dal terminale dalla quale viene usata... > direi che è molto difficile per il cavallo di troia diventare figlio del > terminale in cui hai inserito il comando sudo Le tue informazioni non sono errate e scrivere l'attaccante in modo corretto non è facile. Per questo ho parlato di una larga fascia di utenti: questi sono attacchi che richiedono risorse per essere sviluppati e devono quindi generare un "ritorno economico" che puoi ottenere solo se hai una grande quantità di bersagli. Peraltro un paio di ideuzze le ho. Tutto starebbe a saperle "confezionare" bene: quando ancora gli AT&T 3B2 erano una macchina abbastanza recente un mio amico riuscì ad ottenere una shell setuid col mio user semplicemente facendomi credere di aver trovato quello che cercavo. Spero di essere riuscito a spiegarmi meglio. -- /\ ___Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_ African word //--\| | \| | Integralista GNUslamicomeaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso...Debian" Warning: gnome-config-daemon considered more dangerous than GOTO -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21163.2381.646174.36...@mail.eng.it
Re: gruppi di default in debian jessie
Gian Uberto Lauri scrisse in data 13/12/2013 11:54: Perché di default sudo fa il caching delle credenziali: con la configurazione di default, per alcuni minuti sudo non chiede nuovamente l'autenticazione (su -c non lo fa mai). sai che ho letto la tua mail 2 o 3 volte ma non sono riuscito a capire dove sia il problema di sudo? Ho capito che riguarda la cache ma poi... La cache delle credenziali non è di per se negativa, meglio usare 3 sudo verso programmi binari che far eseguire tutto uno script con l'id 0:0 (parlo dell'id utente), sarebbe meglio avere un'opzione per dire "da qui tieni le credenziali in cache" e oltre a quella già presente "annulla la cache delle credenziali" in modo da controllare il campo di esistenza della transazione. A questo aggiungi che la configurazione di default di Debian e Ubuntu prevede che il primo utente creato compaia in /etc/sudoers come "primo ALL=(ALL) ALL", in pratica fa diventare sudo una copia di su che non richiede di conoscere la password di root. secondo la tua visione direi che è peggio di così: ogni volta che crei un account di tipo amministrativo viene inserito nel gruppo sudo (per debian, admin per ubuntu) che ha appunto i privilegi di cui parli. Questo per dire che non solo il primo account ma ogni account di tipo amministrativo ha quei privilegi. [...] fare un piccolo cavallo di troia che si metta in attesa del momento in cui vede che la cache delle credenziali sia attiva per poi iniettare codice malevolo sfruttando sudo e la configurazione 'utente ALL=(ALL)ALL'. parli di gksudo o di sudo? AFAIK la cache delle credenziali di sudo può essere utilizzata soltanto dal terminale dalla quale viene usata... direi che è molto difficile per il cavallo di troia diventare figlio del terminale in cui hai inserito il comando sudo... per quanto riguarda gksudo invece mi sembra che non abbia affatto cache delle credenziali o mi sbaglio? Ancora non mi hai convinto ma se insiti forse... ;) Piviul -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52aaf3e4.8020...@riminilug.it
Re: gruppi di default in debian jessie
Il 13 dicembre 2013 09:59, Piviul ha scritto: > sa...@eng.it scrisse in data 12/12/2013 14:05: >> >> Usare un editor e /etc/groups pareva poco figo... > > l'ho sempre fatto andando a metter mano a /etc/group ma mi chiedevo: se > esistono certi strumenti avrà un senso e sto cercando di usarli ed in > effetti mi è stato utile: > > sudo usermod -a -G dialout,cdrom,floppy,audio,video,plugdev,netdev > > molto più comodo che aprire il file etc no? > perché... il molto più semplice e sicuro: sudo adduser utente gruppo pare male? -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cantvqs8i0j1+zzwvvookovqcfotdphbcftsafyjcaz_gbx3...@mail.gmail.com
Re: gruppi di default in debian jessie
Piviul writes: > sa...@eng.it scrisse in data 13/12/2013 10:42: > > Lo so. Ma so pure che appena ci saranno in giro un numero sufficiente > > di macchine Linux desktop da rendere la cosa remunerativa, qualcuno > > scriverà un attacco _anche_ per questa caratteristica di sudo, a naso > > all'interno di una di quelle azioni che puntano a colpire quante più > > macchine possibili in modo da riuscire alla fin fine a colpire > > quella/quelle che interessano in modo indiretto. > Sai che non ho capito perché dici che sudo è più pericoloso di un su -c? Perché di default sudo fa il caching delle credenziali: con la configurazione di default, per alcuni minuti sudo non chiede nuovamente l'autenticazione (su -c non lo fa mai). La cache delle credenziali non è di per se negativa, meglio usare 3 sudo verso programmi binari che far eseguire tutto uno script con l'id 0:0 (parlo dell'id utente), sarebbe meglio avere un'opzione per dire "da qui tieni le credenziali in cache" e oltre a quella già presente "annulla la cache delle credenziali" in modo da controllare il campo di esistenza della transazione. A questo aggiungi che la configurazione di default di Debian e Ubuntu prevede che il primo utente creato compaia in /etc/sudoers come "primo ALL=(ALL) ALL", in pratica fa diventare sudo una copia di su che non richiede di conoscere la password di root. Terzo punto (non tecnico): la gente tende ad usare il proprio account con meno "consapevolezza per la sicurezza" rispetto ad un account amministrativo anche quando "si fa delle pare" nel momento in cui usa un account amministrativo. > A me sembra che il problema principale sia che bisogna stare molto > attenti ad eseguire programmi da root sia che essi siano eseguiti > utilizzando sudo che utilizzando direttamente l'utente root. Ottima cosa che tu abbia la consapevolezza di ciò. Ma ci hai mai pensato che è il tuo il più usato account amministrativo e che quindi lo devi difendere con tenacia pari a quella che usi per proteggere l'account di root? Tu si probabilmente, ma appartieni ad una minoranza illuminata. Se invece usi il tuo account "con liberalità" cominciano a presentarsi problemi potenziali. Beninteso, sarebbe questa la forza di GNU/Linux contro i virus, permettere ad un utente di essere compromesso senza compromettere il sistema. Ma il primo utente creato può usare sudo con qualsiasi comando. E le sue credenziali rimangono valide per un certo periodo di tempo. Supponiamo adesso che ci sia una base sufficientemente ampia di utenti Ubuntu/Debian/Fedora (hanno tutte lo stesso comportamento con sudo) da rendere economicamente profittevole fare un piccolo cavallo di troia che si metta in attesa del momento in cui vede che la cache delle credenziali sia attiva per poi iniettare codice malevolo sfruttando sudo e la configurazione 'utente ALL=(ALL)ALL'. Abbiamo un sistema che permette col tempo di crearsi una base di macchine compromesse utili per vari scopi, dalle attività con reddito immediato (le botnet) a cose un po' più fetenti e di ampio respiro. Che so, infettare abbastanza macchine via rete, dispositivi rimovibili come le pennette USB e, perché no, il device audio (ci sono già malaware che usano gli ultrasuoni per comunicare a breve raggio) colpendo indiscriminatamente tutte le macchine possibili fintanto che se ne trova una con le caratteristiche che la fanno riconoscere come bersaglio principale. Fantascienza? Utopia? Paranoia? No. Attacco già avvenuto ai danni dell'Iran, dove sono riusciti a metter fuori uso molte centrifughe per la raffinazione dei materiali radioattivi con un programma chiamato stuxnet. Ergo, visto che i creatori di malaware comunque sono bravi, almeno non facciamogli trovare la pappa pronta ma facciamoli sudare quanto più possibile. > IMHO invece è molto più pericoloso avere l'abitudine ad entrare come > root per fare attività amministrative così come è molto più > intrinsecamente insicuro un sistema di cui un potenziale cracker conosce > già il nome utente dell'utente con i privilegi più elevati... Falsa credenza. C'era chi cambiava il nome degli account amministrativi sentendosi più sicuro. Costa molto di più indovinare una password che aggirarla, e se riesco a sniffare la password riesco pure a sniffare l'username per cui viene usata... In compenso, controllare che grep 0:0 /etc/passwd dia un solo risultato non è così paranoico :) Per la cronaca: non sono un esperto di sicurezza o un black hat, ho ritenuto più utile fare altre cose coi computer. Ma una ventina di anni fa ho avuto la mia dose di divertimento ed ho imparato a pensare male... -- /\ ___Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_ African word //--\| | \| | Integralista GNUslamicomeaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso...
Re: gruppi di default in debian jessie
Il 13 dicembre 2013 11:20, Piviul ha scritto: > Sai che non ho capito perché dici che sudo è più pericoloso di un su -c? A > me sembra che il problema principale sia che bisogna stare molto attenti ad > eseguire programmi da root sia che essi siano eseguiti utilizzando sudo che > utilizzando direttamente l'utente root. neppure io ho capito questa diatriba... sudo comunque funziona da terminale, come su -c, come su ti chiede la password prima di eseguire il comando, ed esegue solo quello... quindi la vedo un po' dura... certo che se tu sei abituato a digitare la tua password ad ogni richiesta, senza sapere che ha invocato il comando... > IMHO invece è molto più pericoloso avere l'abitudine ad entrare come root > per fare attività amministrative anche qui non sono completamente d'accordo... se sai quello che stai facendo ed entri esclusivamente da terminale, grossi problemi non dovrebbero esserci... naturalmente se sei sicuro dei comandi che vai poi a lanciare, ma lo stesso pericolo lo avresti lanciandoli con un bel su -c o sudo. discorso diverso è se forzi il login con interfaccia grafica con root come utente, nel qual caso è impossibile sapere che cosa parte e cosa no... ed è in questo caso facile fare stronzate (ma noi non ci mettiamo mai alla stregua di winzoz pre 7, vero?). > così come è molto più intrinsecamente > insicuro un sistema di cui un potenziale cracker conosce già il nome utente > dell'utente con i privilegi più elevati... > certo... peccato che nell'uso desktop casalingo, la maggior parte delle macchine hanno un unico utente, vuoi perché in famiglia più persone usano lo stesso computer, vuoi perché è solo una persona ad usare il computer... ma anche in ambito lavorativo, non è impensabile (e forse è pure la norma), che un portatile linux autogestito, abbia un solo utente, perché ne sei l'unico utente. Byez -- Gollum1 Tesoro, dov'é il mio teoro... -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cantvqs-gciy-tizdxcey7jhkfb23r9do26zeaykbzh5zp7u...@mail.gmail.com
Re: gruppi di default in debian jessie
sa...@eng.it scrisse in data 13/12/2013 10:42: Lo so. Ma so pure che appena ci saranno in giro un numero sufficiente di macchine Linux desktop da rendere la cosa remunerativa, qualcuno scriverà un attacco _anche_ per questa caratteristica di sudo, a naso all'interno di una di quelle azioni che puntano a colpire quante più macchine possibili in modo da riuscire alla fin fine a colpire quella/quelle che interessano in modo indiretto. Sai che non ho capito perché dici che sudo è più pericoloso di un su -c? A me sembra che il problema principale sia che bisogna stare molto attenti ad eseguire programmi da root sia che essi siano eseguiti utilizzando sudo che utilizzando direttamente l'utente root. IMHO invece è molto più pericoloso avere l'abitudine ad entrare come root per fare attività amministrative così come è molto più intrinsecamente insicuro un sistema di cui un potenziale cracker conosce già il nome utente dell'utente con i privilegi più elevati... Piviul -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52aadf5d.3070...@riminilug.it
Re: gruppi di default in debian jessie
Piviul writes: > sudo usermod -a -G dialout,cdrom,floppy,audio,video,plugdev,netdev > > molto più comodo che aprire il file etc no? Forse. L'è che ho imparato a non aver bisogno di comandi speciali per automatizzarmi la vita. > > Peraltro: > > > > tenere root disabilitato e usare sudo con la configurazione di default > > (ovvero con ALL=(ALL) ALL e la cache delle credenziali disabilitata) è > > - opinione mia e di altri professionisti del settore - una cattiva > > idea. > la cosa è molto, molto ma molto controversa e dibattuta. Lo so. Ma so pure che appena ci saranno in giro un numero sufficiente di macchine Linux desktop da rendere la cosa remunerativa, qualcuno scriverà un attacco _anche_ per questa caratteristica di sudo, a naso all'interno di una di quelle azioni che puntano a colpire quante più macchine possibili in modo da riuscire alla fin fine a colpire quella/quelle che interessano in modo indiretto. -- /\ ___Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_ African word //--\| | \| | Integralista GNUslamicomeaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso...Debian" Warning: gnome-config-daemon considered more dangerous than GOTO -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21162.54941.435551.110...@mail.eng.it
Re: gruppi di default in debian jessie
sa...@eng.it scrisse in data 12/12/2013 14:05: Usare un editor e /etc/groups pareva poco figo... l'ho sempre fatto andando a metter mano a /etc/group ma mi chiedevo: se esistono certi strumenti avrà un senso e sto cercando di usarli ed in effetti mi è stato utile: sudo usermod -a -G dialout,cdrom,floppy,audio,video,plugdev,netdev molto più comodo che aprire il file etc no? Peraltro: tenere root disabilitato e usare sudo con la configurazione di default (ovvero con ALL=(ALL) ALL e la cache delle credenziali disabilitata) è - opinione mia e di altri professionisti del settore - una cattiva idea. la cosa è molto, molto ma molto controversa e dibattuta. Ciao e grazie Piviul -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52aacc7a.7080...@riminilug.it
