Newsgroup: it.comp.os.linux.sys
Titolo: una cagata pazzesca (che torna utile)

il tuo amministratore di sistema (in quel caso in cui non sia tu stesso), 
è uno di quelli tosti,e  ha stabilito che *tu* per usare sudo devi sempre 
immettere la password.
per fargli un dispetto, e perché ti rompe la palle digitare sempre la tua 
password, tu fai così:
echo passwordsegreta > ~/miapassword
per fargli ancora più dispetto fai così, e inficiare la sicurezza del 
sistema fai così:
chmod 777 $HOME;  chmod 666 ~/miapassword
In questo modo tutti potranno leggere la password che tu usi per 
diventare root
A questo punto fai così:
cat ~/password |sudo -S ls
Tutto ciò è previsto da sudo, e mi è comodo, ma non ne capisco la ragione.
A me sembra un workaround per inficiare la direttiva che fa si che tu 
debba immettere una password per usare sudo.
mah... razza strana 'sti informatici.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 diventare root
C'e' qualcosa che non torna.

 Tutto ciò è previsto da sudo, e mi è comodo, ma non ne capisco la ragione.
Domanda:
Cosa succede allo stdin del programma lanciato da sudo?
bye,
-- 
piergiorgio

> diventare root
Chi può essere tanto imbecille da permettere a MaxAdamo di accedere come 
root a un sistema????
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.



Certo che c'è qualcosa che non torna. C'è un meccanismo che può essere 
aggirato "legalmente".
Questo è il motivo per cui ho scritto questa cosa.


 root a un sistema????
/me morto


Vabbeh scusa se tu hai l'accesso a root (anche se tramite sudo) è
chiaro che puoi fare quello che ti pare, no?
L'errore è di base se proprio vogliamo...



Non saprei dire. I programmi vengono eseguiti regolarmente.
In realtà la discussione è più ampia ... chiunque puo' mettere a rischio 
la sicurezza, e ove sudo non avesse questa opzione ci sarebbe sempre il 
buon "expect" che farebbe sempre gli stessi danni.
A questo punto una cosa è sicura: se le cose stanno così, usare l'opzione 
"NOPASSWD" è meno dannoso.



Facebook: Massimo Bacilieri

 aggirato "legalmente".
Non mi sembra che aggiri niente, che tu scriva la password o che la
passi in pipe con un cat, sempre la devi passare a sudo.
Ma soprattutto, non è che fai cose che l'amministratore non ti ha
concesso, potrai "sudizzare" solo i comandi per i quali ti è stato dato
il permesso di farlo.
Non mi sembra che il tuo workaround permetta di fare qualcosa di più di
quanto concesso, ecco.




ma chiaro questo.... solo che rido per altri motivi.
Rido perché in quel modo ti danno l'opportunità di lasciare una password 
in giro che è più pericoloso ancora.
In certi posti mi si dice: no la password di root non te la possiamo 
dare, però ti possiamo dare accesso "sudo". E fin qui mi sta bene perché 
loro hanno politiche di gestione delle password, e cambiano le password 
con certe scadenze.
Però rido se mi impostano l'opzione per richiedere l'immissione della 
password.
Anche se non ci fosse quella opzione di "sudo", io mi installerei expect 
nella mia home dir (come facevo ai tempi quando ero utente della sunray) 
e farei sudo ugualmente senza immettere la password.


 un dispetto al sysadmin"...
ma non era questo il punto.... uffa.
Il punto è che l'opzione per richiedere la password, che qualcuno usa 
come garanzia di maggiore sicurezza, vista la realtà, si presenta come 
opzione meno sicura.... senza nemmeno contare che c'è per default il buco 
dei 5 minuti (che dovresti azzerare con "sudo -k").
Poi c'è pure expect... c'è perl-expect.... insomma, quella opzione IMHO 
non serve a garantire maggiore sicurezza.


 Questo è il motivo per cui ho scritto questa cosa.
credo che mark intedesse:
se puoi divetare root e non sei l'amministratore di sistema, cè qualcosa
che non torna.
ndr: essere suder e poter diventare root sono due cose ben distinte, a
meno che tu non abia sempre e solo usato ubuntu desktop.Ma non credo che
sia il caso, o sì?

 
se io metto in .bashrc:
alias pippo='echo pass_segreta|sudo -S '
io faccio quello che il mio amministratore non vuole che faccia, visto 
che non mi ha messo l'opzione in sudo.
Peggio, visto che chiunque lanci il comando "alias" potrà vedere la mia 
password.
Chiariamo una cosa. Io non metto la mia password nel file di 
inizializzazione della shell, ne tantomeno la metto dentro a un file di 
testo. Era un semplice esempio.


 debba immettere una password per usare sudo.
Ma la pass la devi conoscere comunque...
Stai confondendo il concetto di "immettere la pass
da terminale" con "conoscere la pass".
bye,
-- 
piergiorgio

 sia il caso, o sì?
dai che cazzo di domanda è? Mi stai chiedendo quanto ce l'ho lungo? Come 
molti di noi, avendo lavorato in Sun ho lavorato su solaris, ho lavorato 
su HP partizionati, su Aix, su mainframe. Ma sul mio desktop cosa vuoi 
che usi?
Su un desktop e su un notebook uso ubuntu e su un netbook uso windows xp. 
Quando i miei colleghi che usano prevalentemente windows mi parlano di 
openbsd gli abbasso la testa e gli dico: si si bello è.




beh.... se non entri con chiave pubblica la devi conoscere. Altrimenti 
non ti muovi.
Il problema a mio avviso è:
da un lato se abbandoni la console, qualcuno può lanciare sudo al posto 
tuo. Ad ogni modo, se non hai lanciato "sudo -k" avrà - per default - 5 
minuti di tempo per lanciare sudo senza password.
dall'altro lato, se qualcuno decide di mettere la password in chiaro 
tramite expect, o tramite "sudo -S" io lo trovo molto più pericoloso.


 root a un sistema????
Sai, per uno che ha ribadito piu` e piu` volte che non vale la pena
leggere quello che dice Adamo, ti preoccupi un po' troppo di sfancularlo
ogni volta che hai l'occasione di leggere un suo post (ovvero, se ti sta
sul cazzo ignoralo e fregatene di quello che scrive ma, soprattutto,
facci il favore di non sentirti l'obbligo di scrivere post spazzatura
contro di lui al solo scopo di creare inutile rumore)
Enrico

 passi in pipe con un cat, sempre la devi passare a sudo.
Personalmente la trovo comunque una cosa dannosa in quanto ti permette
di automatizzare in chiaro qualcosa che non dovrebbe esserlo
Enrico

 password.
Aspetta, c'e` da dire che, se non ricordo male, sudo richiede la
password dell'utente con cui sei connesso, e non la password di root. In
questo caso e` si un problema non da poco (potenzialmente potresti
permettere dei possibili accessi alla tua rete), ma c'e` comunque da
dire che sei limitato nelle tue operazioni (a meno che sudo non sia
stato impostato in modo che tu possa fare tutto e il contrario di tutto)
Enrico
P.S. comunque, ecco un altro buon motivo (per me) per non usare sudo

 password dell'utente con cui sei connesso, e non la password di root.
Chiaro. Questo era molto ultra-sottintesto :) E' la tua la password che 
devi immettere.
Chiaro che se devi conosce la password di root, allora a cosa serve sudo? 
A quel punto fai "su -", oppure ssh root@xxxx


 mah... razza strana 'sti informatici.
Se è per quello l'utente può semplicemente scrivere la password su un
post-it ed attaccarla allo schermo.
Come si dice: al mal dello sciocco non v'é rimedio.



però passwd, telnet, ssh non accettano dati da stdin.
Ovvero il problema non è insito, come in questo caso.
Comunque basta. Come disse Stallmann, persino il gruppo wheel è fascista 
e tutti devono poter essere root :)
23.5.1 Why GNU su does not support the ‘wheel’ group
(This section is by Richard Stallman.)
Sometimes a few of the users try to hold total power over all the rest. 
For example, in 1984, a few users at the MIT AI lab decided to seize 
power by changing the operator password on the Twenex system and keeping 
it secret from everyone else. (I was able to thwart this coup and give 
power back to the users by patching the kernel, but I wouldn't know how 
to do that in Unix.)
However, occasionally the rulers do tell someone. Under the usual su 
mechanism, once someone learns the root password who sympathizes with the 
ordinary users, he or she can tell the rest. The “wheel group” feature 
would make this impossible, and thus cement the power of the rulers.
I'm on the side of the masses, not that of the rulers. If you are used to 
supporting the bosses and sysadmins in whatever they do, you might find 
this idea strange at first. 


 ragione.
Hai presente quando devi lanciare comandi con sudo da script che
girano da soli (cron, at, etc)?
Se poi sei cosě furbo da scrivere la tua password in un file a+r non
č mica colpa dell'amministratore di sistema :-/
-- 
ValeRyo
CBR600F "Cerbero" - 
http://www.slimmit.com/go.asp?6YT
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 password dell'utente con cui sei connesso, e non la password di root.
Dipende da come lo configuri.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 di automatizzare in chiaro qualcosa che non dovrebbe esserlo
IMHO il fatto che sudo possa leggere la password dallo stdin non
è affatto di per sé una scemenza. Ci sono modi intelligenti per
sfruttare la cosa (che so: magari leggere una pwd, generata casualmente,
da una chiavetta usb).
Inoltre, le cavolate uno trova *sempre* il modo di farle, se vuole. ;)
Ciò detto, io francamente non vedo di che cosa discutiamo. ?-)


 password.
Eh?
I tuoi alias li vedi solo tu.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 devi immettere.
E sei *TU* che ne rispondi, forse anche penalmente (IANAL).
Ci sono modi molto più semplici per farsi del male da soli.


 di automatizzare in chiaro qualcosa che non dovrebbe esserlo
Mah, anche rm ti permette di piallare il disco, se coi privilegi di
superuser fai rm -rf / , non è che per questo rm sia un comando dannoso.
Secondo me è un po' una questione di lana caprina.
Anche perché se anche trovassi il modo di rendere obbligatoria la
digitazione della password, ma uno per non scordarsela la salvasse in un
file "password" nella sua home, facendo tutti i giochini indicati da
Max_Adamo, direi che saremmo daccapo. Quindi il problema non è sudo che può
prendere la password dallo stdin, ma il fatto che gli utenti non devono
essere delle bestie.
Poi potremmo anche parlare dei sysadmin che pur sapendo di avere degli
utenti bestia, danno loro ugualmente permessi di superuser con sudo...


 questo mi trovo nella situazione ridicola dove io faccio "sudo su" 
Tipo così:
ulibarra@cerbero:~$ sudo su
[sudo] password for ulibarra:
Sorry, user ulibarra is not allowed to execute '/bin/su' as root
?
Dipende tutto da come imposti sudo. Se i tuoi sysadmin sono mentecatti,
è mica colpa di sudo.
-- 
Massimo Bacilieri AKA Crononauta


 molto più semplici per farsi del male da soli.
no per favore.... non la mettiamo su questo piano. Ero nel campo delle 
ipotesi pure. Nella realtà io continuo a immettere la password quando 
richiesto.
Il discorso era a un livello più astratto.


 I tuoi alias li vedi solo tu.
ma anche il mio "sudo" lo posso lanciare solo io.
Sveglia. La situazione è quella in cui tu abbandoni il terminale e 
qualcuno altro ci mette le mani.
In questo caso se non hai lanciato "sudo -k" potrà usare anche sudo se tu 
lo avevi usato negli ultimi 5 minuti.


 mica colpa dell'amministratore di sistema :-/
si si ... ma nel 99% dei casi viene usato erroneamente per scopi diversi.


 ci mette le mani.
E non ti logghi fuori?
O non blocchi lo schermo?
Come si diceva: se uno si mette d'impegno, a cercarsi i guai... ;)


 lo avevi usato negli ultimi 5 minuti.
Anche se non freni agli stop, sai, puoi correre dei rischi.
Lo sai, no, che l'universo è una battaglia continua tra i sysadmin
che cercano di fare procedure a prova di imbecilli, e il creato che
sviluppa imbecilli sempre più perfezionati?


 Il discorso era a un livello più astratto.
IL livello astratto che hai prospettato è che qualcuno faccia
una tafazzata, a suo esclusivo danno.
E non c'e' bisogno di fare tutti i giri che hai fatto tu, come
ti hanno già detto: basta il post-it sotto la tastiera.


 contro di lui al solo scopo di creare inutile rumore)
Facci? o fammi? Io penso che sia molto più rumoroso il tuo post che è 
decisamente più inutile di quello cui hai risposto (che era in estrema 
sintesi solo una battuta).
Direi anche che sono più rumorosi i post di risposta al quesito dell'OP (che 
mi son preso la briga di andare a leggere) dato che è un messaggio idiota, 
che parte da presupposti errati e applicando concetti errati giunge a 
conclusioni errate.
Eppure c'è chi risponde anche seriamente a tali idiozie... forse sarebbe 
meglio che si facessero più battute, almeno si alza il buonumore.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 Dipende da come lo configuri.
scusa, ma se per usarlo devi conoscere la password di root a cosa serve 
sudo?


 è mica colpa di sudo.
Di nuovo....
in aziende dove i server sono più di XXX la norma è che la gestione delle 
password di root è in mano a un frontoffice che cambia le password 
secondo i tempi prestabiliti.
Lo scenario usuale e che tu non puoi avere la password di root perché 
viene cambiata ogni tot tempo, ma hai bisogno di lavorare come root.


 Come si diceva: se uno si mette d'impegno, a cercarsi i guai... ;)
senti, spiegami qual è l'utilità di richiesta password tramite sudo e 
facciamo prima.
Io poi ti spiego che nel 99% dei casi l'uso che se ne fa è sbagliato e 
abbiamo chiuso la discussione.




Visti i risultati, sono convinto che i killfile sono ancora più inutili 
della password di sudo.


 Ciò detto, io francamente non vedo di che cosa discutiamo. ?-)
eeh... non me ne parlare....


 disponibile è quella "over ldap"
Puoi usare pam, eh.

 diversi.
No, davvero non capisco cosa intendi.
Per me il 'sudo con password' è semplicemente qualcosa per ricordare
all'utente che sta entrando in un campo minato e deve fare attenzione a
quello che fa (tra quello che gli è consentito fare, ovviamente).
E se la password già la usa per fare login, non vedo perché gli costi tutta
questa fatica inserirla anche quando deve fare sudo.
Se poi deve fare sudo parecchie volte in una sessione non è un utente, è un 
admin.


 facciamo prima.
Far capire all'utente che sta per fare qualcosa coi permessi di root.
Utile, per esempio, quando infili sudo in uno script e l'utente lo esegue 
senza digitare fisicamente esse-u-di-o.
Bye.


ok.... mettiamo però le cose secondo un certo ordine storico,
altrimenti non ci si capisce nulla.
-> prima venne "sudo" che è vecchio come il cucco.
-> e il settimo giorno fu inventato il token.
Chi ha fatto sudo non poteva pensare al token ante-litteram.
Cioè, è qualcosa che noi potremmo appioppargli, ma non è stato
concepito certamente per questo.

 viene cambiata ogni tot tempo, ma hai bisogno di lavorare come root.
Devo ancora riuscire a capire l'utilità di tenere segreta la password di
root e cambiarla periodicamente, ma poi abilitare gli utenti a fare sudo su.
Tantovale comunicare la password di root, funzionalmente è uguale.
Il problema, di nuovo, non è come funziona sudo, il problema sono policy di
sicurezza quantomeno discutibili (per non dire di peggio).


 facciamo prima.
Se ti danno dei privilegi, tu li usi.
Se qualcuno usa il tuo pc ed hai lasciato per errore la sessione aperta un 
altro teoricamente (a parte il tempo di 5min) non ci riessie.
Un po lo stesso motivo che quando cambi password ti chiede quella attuale...
Ciao,
ScriptJus 

 sudo?
ti chiede quella dell'utente non di root.
Ciao,
ScriptJus

 ti chiede quella dell'utente non di root.
ops scusa non avevo letto sopra...
chiedo umilmente perdono..
Ciao,
ScriptJus

On 27 Mar, 11:25, "ScriptJus"

infatti.... stavo per sentirmi preso in giro. Dici una cosa e ti
tirano le pietre, dici il contrario e ti tirano le pietre :)

 No, davvero non capisco cosa intendi.
Lui pensa che ubuntu sia uno standard.
Si vede che non aveva mai incocciato sudo in precedenza, e non
aha la minima idea che è root che decide, secondo le policy, cosa
far fare con sudo.


 senza digitare fisicamente esse-u-di-o.
si, questa era l'unica utilità che io riuscivo a trovare.


capisco... in linea di massima il concetto è che ci sono policy per il
cambio delle password per tutti gli utenti, a maggior ragione queste
policy vengono applicate a root che è il dio della macchina.
Se hai mille server, non puoi affidare a mille persone diverse (che
oggi ci sono e domani scompaiono) la gestione di mille password di
root.
Tu sei responsabile per la tua password, ma chi deve gestire il cambio
password di root?
Chiaramente lo fa un ente preposto, che si occupare di gestire le
password di root su mille server.

 password di root su mille server.
Continuo a non capire che differenza faccia comunicare direttamente la
password di root, oppure dare agli utenti la possibilità di fare sudo su,
diventare root, e due secondi dopo fare passwd per reimpostare la password
di root nonché andare in giro a piallare il sistema a piacere.
Il problema, ripeto, non è tecnico, è organizzativo. È demenziale voler
blindare le password di root, e poi lasciare gli utenti liberi di fare sudo
su. "Sudo su" è un utilizzo di sudo nato e pensato in ambienti desktop
oriented che si suppongono essere poco più che macchine single-user, giusto
per fare in modo che l'utente - che si presuppone anche amministratore e
proprietario della macchina - possa prendere alla bisogna i privilegi di
root con la password del proprio utente.
Replicare questa struttura in ambienti enterprise, vuol dire dare i permessi
di root ai semplici utenti. Diventa irrilevante il discorso di sudo, il
problema qui è avere degli utenti, diversi dallo staff di amministrazione,
che può prendere i permessi di root sulla macchina.
In questi casi, sudo va usato in modo decisamente più restrittivo, diciamo
che viene in aiuto al limite di Unix di non permettere di su-idare degli
script (ma solo gli eseguibili). Tutto - come al solito - dipende da come
viene configurato e impiegato, nulla è buono o cattivo di per se.


 Tantovale comunicare la password di root, funzionalmente č uguale.
Nahh io ho configurato il mio bel sudoers, perche l'utente apache permetta 
l'esecuzione di un singolo script (e nulla altro) che riavvii il servizio 
dhcp. (Meglio questo di scrivere in charo la password di root su un codice 
php.)
Ho creato alcune paginette in php per registrare i computer con relativo mac 
address.
In questo modo limito il rischio di sprovveduti (chi ne sa qualcosa sa come 
ovviare ovviamente) che attaccano il cavo di rete a computer non 
autorizzati.
Ciao,
ScriptJus 

 sudo?
Beh, direi che anche in questo caso svolge la sua solita funzione.
L'opzione può aver senso soprattutto se la password di root
si differenzia dalle altre per lunghezza e sicurezza (e viene
rinnovata spesso).


 casualmente da una chiavetta USB?
Intendevo questo: tu hai la bella idea di usare una pwd
sicura per root, il che significa un bel po' di caratteri casuali.
Non la mandi a memoria, ma la conservi gelosamente in un file, su una
chiavetta usb crittata. Diventa comodo leggerla da lì, non ti pare?


 Beh, direi che anche in questo caso svolge la sua solita funzione.
ma hai letto i commenti di scriptjus (i due messaggi) prima di
continuare a rispondere?

 chiavetta usb crittata. Diventa comodo leggerla da lì, non ti pare?
Questo mi può star bene.... solo che tu  parlavi di "random" nel tuo
precedente messaggio.

 di root nonché andare in giro a piallare il sistema a piacere.
guarda non lo dire a me.... comunque è una questione pratica di
gestione e non di sicurezza.
root non è un utente personale, e la sua password non puo' essere
gestita individualmente, perché i server sono spesso condivisi,
percheé le persone cambiano lavoro.
Ci sono team preposti per fare queste cose su tutti i server.

 Ci sono team preposti per fare queste cose su tutti i server.
Ti ripeto, perché forse non è chiaro: se dai a un utente la possibilità di
fare "sudo su" su una macchina, nei fatti gli hai dato la password di root,
anche se in realtà usa quella del suo utente.
Oltretutto, dopo che ha fatto sudo su e passwd per cambiare la password di
root, i genialoidi dello staff di amminstrazione si fanno le seghe con le
loro policy, perché per recuperare l'accesso a quella macchina, l'unica è
accedervi fisicamente e resettare la password di root.
Alla faccia della semplicità gestionale.


 precedente messaggio.
Beh, probabilmente non ero stato superchiaro.
Il fatto che la pwd sia generata random è appunto quel che rende difficile
mandarla a mente, specie se lunga.


 continuare a rispondere?
Sì sì. :)


 accedervi fisicamente e resettare la password di root.
Ma no, accedono come mariorossi, con la sua password, e poi vanno
di "sudo su".


 di "sudo su".
Una 'sudo war', insomma :-)


 Sì sì. :)
compreso il secondo? E allora?

 compreso il secondo? E allora?
E allora niente. Ribadisco quanto già scritto, e fine.


 decide, secondo le policy, cosa far fare con sudo.
fossi un nerd di quelli fighi potrei anche stare ad ascoltarti.
Uso ubuntu da pochissimo tempo.
Piuttosto ho sulle spalle una esperienza relativa ad una configurazione 
di sudo over ldap su 600 server hp-ux. Diversi anni fa. So bene a cosa 
serve sudo .... e a cosa non serve.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 serve sudo .... e a cosa non serve.
Beh, scusa, non sembrerebbe.



Facebook: Massimo Bacilieri

 A quel punto fai "su -", oppure ssh root@xxxx
No dai, magari ssh root@xxx non lo facciamo. :-D
Cmq per quello che conta, io non vedo tutta sta utilita' di sudo.
:-)

 Cmq per quello che conta, io non vedo tutta sta utilita' di sudo.
E cosa useresti per far eseguire programmi sotto contesti utente differenti? 
suid a raffica?
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.



Crono... non è una questione prettamente di sicurezza. Questo è chiaro.
Mettiamola così, stile disegnigno, con uno scenario tipico "enterprise":
4 persone hanno accesso alla stessa macchina, uno deve gestire oracle e 
non so perché gli serve root, uno deve gestire l'applicazione xxx, 
un'altro gestisce il cluster, e uno deve fare dei restart applicativi che 
gli richiedono di essere root. Mettiamo da parte il discorso che si può 
assegnare sudo per ogni comando.
queste persone non si conoscono tra loro, lavorano in team diversi, e in 
città diverse e *soprattutto* nessuno sa niente dell'altro. La persona 1, 
non sa che esiste la persona 2 eccetera...
Allo stesso tempo c'è la necessità di cambiare tutte le password ogni 
mese, compresa quella di root.
La password  di root deve essere gestita quindi da un'altra persona 
ancora.
Ora cosa facciamo? Questa persona cambia la password e la comunica agli 
altri 4?
Non funziona. Perché quello che gestisce le password, gestisce altri 500 
server e per lui è complesso sapere chi sono tutti gli owner e tutte le 
persone che devono lavorare sulla macchina.
Molto semplicemente, quelle 4 persone gestiranno le loro password 
relative agli account nominali e useranno sudo per diventare root, e 
l'altra persone gestirà le password di root su tutti i server.
e tutti vissero felici e contenti.


 Beh, scusa, non sembrerebbe.
ogni volta che uno mette in discussione il verbo "non sembrerebbe".
E' quasi sempre così.


 difficile mandarla a mente, specie se lunga.
o sei troppo avanti o sei troppo fuori.
io propenderei per la seconda.... non ti incazzare ma mi spieghi cosa ci 
fai con una password random, se non si tratta di un qualche token?


 random, se non si tratta di un qualche token?
Senti: invece di scegliere come password "lavispateresa", 383wwwpippo" o
"sarcazzodelimortaccisua", che sarebbero pure facilmente memorizzabili, uso
uno dei tanti modi disponibili (magari uno degli script appositi) per
generare, e per rinnovare di tanto in tanto, la password di root. La faccio
pure bella lunga.
'Zzo faccio co' sta password? L'unica cosa praticabile è gestirla salvandola
in un file, perché memorizzarla sarebbe una fatica, e inserirla a mano ogni
volta dalla tastiera lo sarebbe altrettanto.
Allora salvo 'sta password, generata casualmente (è chiaro, ora, che intendo
con "generata casualmente"? Non "casualmente e on the fly") su una
chiavetta usb, dentro a un file, e quando mi serve immettere la pwd di root
inserisco la chiavetta, monto il fs e faccio leggere a sudo la pwd dal file.
Poi smonto il device, tolgo la chiavetta e la conservo gelosamente.
In certi casi, 'sta roba può esser utile. In altri no.
In certi casi sudo è utile, in altri no. Ma esistono, sì!, casi in cui è
utile, esistono situazioni in cui il fatto che possa leggere la pwd dallo
stdin è davvero utile: non serve solo a provocare disastri. Io ho sempre
inteso dire solo e soltanto questo.


 non si tratta di un qualche token?
Senti: invece di scegliere come password "lavispateresa", 383wwwpippo" o
"sarcazzodelimortaccisua", che sarebbero pure facilmente memorizzabili,
uso uno dei tanti modi disponibili (magari uno degli script appositi) per
generare casualmente la password di root. La faccio pure bella lunga.
Uso lo stesso metodo per rinnovarla, di tanto in tanto.
'Zzo faccio co' sta password? L'unica cosa praticabile è gestirla
salvandola in un file, perché memorizzarla sarebbe una fatica, e inserirla
a mano ogni volta dalla tastiera lo sarebbe altrettanto. Allora salvo 'sta
password, generata casualmente (è chiaro, ora, che intendo con "generata
casualmente"? Non "casualmente e on the fly") su una chiavetta usb, dentro
a un file, e quando mi serve immettere la pwd di root inserisco la
chiavetta, monto il fs e faccio leggere a sudo la pwd dal file. Poi smonto
il device, tolgo la chiavetta e la conservo gelosamente.
In certi casi, 'sta roba può esser utile. In altri no.
In certi casi sudo è utile, in altri no. Ma esistono, sì!, casi in cui è
utile, esistono situazioni in cui il fatto che possa leggere la pwd dallo
stdin è davvero utile: non serve solo a provocare disastri. Io ho sempre
inteso dire solo e soltanto questo.
-- 


 "sarcazzodelimortaccisua", 
Lem... cacchio, sii più chiaro la prossima volta.
Io uso keepassx, che memorizza password e se vuoi te le genera. Il tutto 
viene memorizzato in un filetto, e questo filetto (che non è il filetto 
di vitello)... può essere memorizzato su una periferica esterna.
Da come la avevi scritta, sembrava che tu generassi all'istante pass 
random all'istante, per poi utilizzarle e mo' di token che cambiano 
sempre.


 
No e' che probabilmente non ho mai avuto l'esigenza vera di usarlo.
Sinceramente dover usare sudo al posto di fare su e avere la console di 
root non la vedo.
Lavoro da root e le conseguenze le conosco.
Sbaglio amen, colpa mia.
Evidentemente da come ne parli viene utile in altri modi che altrettanto 
evidentemente io non conosco :)
(carenza mia)

 assegnare sudo per ogni comando.
Ecco, il punto è proprio questo: PERCHE' CA%%O metterlo da parte?
Per pigrizia? Allora smetti di lamentarti delle caratteristiche
di sudo, e lamentati della pigrizia o inettitudine di "root".
sudo nasce per lasciar fare qualcosa, a qualcuno, e quel qualcuno
e quel qualcosa lo decide root.
Se root non sa o non vuole fare il suo mestiere, sudo cosa ci può
fare?


 
Beh, io insisto nel dire che se root lascia fare agli utenti, con sudo,
tutto ciò che può fare root, e viene chiuso fuori, si metta a pedalare,
visto che ha voluto la bicicletta.


 No e' che probabilmente non ho mai avuto l'esigenza vera di usarlo.
questo è un alto paio di maniche.
Sgomberiamo innanzitutto il campo dal caso Ubuntu. L'uso che se ne fa in 
Ubuntu ha ragioni diverse, per un uso desktop, che a noi non interessano 
(lì la configurazione predefinita prevede che root è senza password per 
evitare di dover spiegare al neofita cos'è root e così via. Come 
configurazione "desktop per tutti" è ottimale).
Tornando all'ambiente server enterprise:
In solaris, si possono usare le trusted extensions al posto di sudo, ma, 
in un ambiente misto, dove sudo magari è sotto LDAP, non conviene usare 
cose diverse a secondo dei sistemi, e dover mantenere configurazioni 
diverse....
L'esempio più esplicativo di utilizzo di sudo è quello di un helpdesk che 
potrà usare solo 'useradd', 'usermod', 'userdel'


 lamentati della pigrizia o inettitudine di "root".
noooo. Non è per pigrizia.
Temp fa io gestivo configurazioni sudo estremamente complesse, per un 
ambiente di 600 server HP-UX. E non è un vanto. E' una cosa che ciascuno 
di noi, con un minimo di criterio potrebbe fare. C'erano configurazioni 
per l'helpdesk, configurazioni per i DBA e così via.
Il punto è che in questo momento non mi interessa parlare di come 
funziona sudo nel dettaglio.
Invece ti faccio un esempio preciso, su me stesso: io oggi gestisco una 
applicazione che gira su 21 (ventuno) server linux, con cluster 
applicativi e cluster HP.
Questa applicazione, se non si è root non si può gestire. Pertanto mi 
hanno dato il "sudo ALL".... ovvero "sudo su".
Però, io non ho l'onere di gestire le password dei server. E ti spiego 
perché. Quella macchina è collegata ad esempio ad uno storage emc2. 
Quello storage non lo gestisco io, ma un altro team. Il cluster HP, 
aum_aum me lo gestisco io. Però se sono richieste modifiche al cluster, 
per policy non le posso applicare io, Se bisogna fare utenze applicative 
nominali (useradd, userdel) questo è un lavoro da helpdesk e non lo 
faccio io.
Queste cose le fanno team diversi, e io non so chi sia l'helpdesk che 
lancia useradd o la persona che gestisce lo storage e non ho nessuna 
intenzione di gestire la password di root e doverla comunicare a gruppi 
che nemmeno so che esistono.
Per fare ciò, esiste un apposito gruppo che si occupa di ciò su tutti i 
server.


 assegnare sudo per ogni comando.
Non vedo perché metterlo da parte, visto che sudo nasce principalmente
per quello. Comunque ho capito l'esigenza, resto però dell'idea che sia
una solenne puttanata! :-)
-- 
Massimo Bacilieri AKA Crononauta


 evidentemente io non conosco :)
Normalmente quando hai un utente a cui vuoi consentire di eseguire certi 
comandi come altro utente; per esempio per permettere all'utente con cui 
gira il web server di eseguire un comando privilegiato senza dover fare 
salti mortali e mantenendo il controllo su quel che avviene. L'alternativa 
sarebbe per esempio mettere in piedi un demone e una comunicazione su 
socket, inutilmente complicato nel 99% dei casi.


 una solenne puttanata! :-)
Sono abbastanza d'accordo sul fatto che sia una puttanata... l'unica cosa 
che volevo aggiungere (tramite questo thread) è che richiedendo la pass 
all'utente la puttanata resta tale e quale... se non peggiore per certi 
aspetti.


 visto che ha voluto la bicicletta.
Appunto, è quello che dico anch'io: se root concede a degli users i
permessi di root, allora tantovale dare la password di root e smetterla
di farsi tante seghe sui cambi password di root a scopo "sicurezza".


 comunicazione su socket, inutilmente complicato nel 99% dei casi.
Minchia, direi! È come usare una bomba atomica per insetticida :-O


 hanno dato il "sudo ALL".... ovvero "sudo su".
Bella applicazione di merda eh.


 Bella applicazione di merda eh.
non posso non approvare.... ammetto che si tratta di un esempio un po' 
fuori dalla norma.
Il problema secondario è dovuto anche al fatto che questa applicazione ha 
diverse componenti (ldap, postgres, tomcat, il suo db proprietario, 
etcetera...) che richiedono tutte privilegi.


Non conoscevo questo aspetto di sudo
quindi mi pare di capire che puo' essere "blindato"
ovvero decidere precisamente quale comando/i "delegare"
Sapendo questo ritiro la mia affermazione/parere iniziale.
A questo punto dovessi essere l'utente che utilizza questo/i comando/i 
che normalmente sarebbero competenza di root, credo che mi chiederei 
anche io il motivo di dover inserire sempre la password.
Andando con una logica direi che se e' stato previsto che io usi questi 
comandi significherebbe che questi fanno parte del mio lavoro.
E' quasi come dire che per lavoro devo usare la fotocopiatrice perche' 
parte del mio lavoro e' produrre copie di documenti, ma ogni volta che 
devo fotocopiare devo chiedere il permesso per usarla.
A sto punto pero' probabilmente il problema non e' sudo ma chi ha deciso 
di implementarlo in questo modo. (no?)
:)

 di implementarlo in questo modo. (no?)
E` alquanto configurabile, a volte anche troppo.
bye,
-- 
piergiorgio

 anche io il motivo di dover inserire sempre la password.
Mica detto che tu debba. Puoi configurare anche questo.
man sudoers
sarà una lettura illuminante. ;)


 di implementarlo in questo modo. (no?)
Questo è implicito, ed è il motivo per cui ho detto che il post che ha 
iniziato il 3d è idiota.


 Hai l'opzione per richiedere la pass (utente) oppure no.
si ma abbiamo detto che è aggirabile tramite "sudo -S" .... noooo non ho 
detto niente, non è vero, basta chiudiamo il thread più lungo del mondo :)


 sarà una lettura illuminante. ;)
sarebbe stato altrettanto illuminante leggere il mio post iniziale....


 hanno dato il "sudo ALL".... ovvero "sudo su".
ma perchè non un sudo applicazione (semplifico, ovviamente)?
Ciao,
ScriptJus 

 si ma abbiamo detto che è aggirabile tramite "sudo -S" .... noooo non ho 
Non e` aggirabile, devi sempre immettere *la* pass.
Ti ripeto, tu stai confondendo il fatto di dover
scrivere la pass da terminale con il fatto che
serva una pass (o meno).
bye,
-- 
piergiorgio

 ma perchè non un sudo applicazione (semplifico, ovviamente)?
Ops, ultimamente posto troppo velocemente...
...vedo e capisco il motivo.
Non ho lavorato moltissimo con sudoers, ho fatto solo qualche piccolo 
esperimento.
No notato che all'occorrenza si possono mettere delle eccezioni, nel man ci 
sono proprio un po di esempi con su e shells...
Ciao,
ScriptJus

 terminale con il fatto che serva una pass (o meno).
alias pippo='echo miapassword | sudo -S'
l'utente malintenzionato che dovesse entrare, digiterà alias e troverà 
l'alias pippo.
Secondo me quella funzionalità va usata per scopi diversi, all'interno di 
script (come è stato detto).
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 script (come è stato detto).
Ovviamente.
bye,
-- 
piergiorgio

 alias pippo='echo miapassword | sudo -S'
In questo caso l'inserimento della password c'è *comunque*,
ma viene fatto dallo stdin.
La cosa può esser realizzata in vari modi, e aver senso o no.
Nel dettaglio, il modo che paventi tu qui sopra è naturalmente osceno,
per quanto è rischioso.
Invece si ricordava che si può configurare sudo perché la password
non sia proprio richiesta. L'appunto riguardava un'affermazione assoluta,
e falsa, sul comportamento di sudo, affermazione che prescindeva dallo
sviluppo del filone.
Ma che ti piglia, eh?
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php


Facebook: Massimo Bacilieri

 meglio che si facessero piů battute, almeno si alza il buonumore.
Forse perche` e` questo il concetto di "discussione". Se non ti
interessa, ignora il thread e amen. Ma insultare una persona che tu
stesso ammetti di aver messo nella lista di ignore ti mette allo stesso
livello di un troll di pessima categoria
Enrico
P.S. per essere piu` chiari, a me non da fastidio il fatto che qualcuno
ha insultato Adamo, ma che qualcuno ha insultato qualcun altro a
prescindere (anche perche` a te ti ritengo una persona abbastanza
intelligente da evitare cadute di stile del genere)

 produce il postit?
Decisamente al monitor... :-)
Tra l'altro, l'utente "malintenzionato" che trova la
sessione aperta, installa tanti di quei key-logger,
che tutta la gerarchia it.comp viene a sapere quanti
peli (non dico dove per rispetto alle signore che
leggono) ha lo sprovveduto...
bye,
-- 
piergiorgio

 intelligente da evitare cadute di stile del genere)
Enrico, sperando di non innescare altre polemiche, ti dico che le uniche 
due che hanno dichiarato a tutti di avermi messo in ignore, sono le 
stesse persone che vanno a leggersi *tutti* i miei messaggi attraverso le 
risposte, senza perderne nemmeno uno.
Dell'altra persona non faccio non faccio il nome, perché io voglio 
superare le polemiche... e anche perché dopo anni e anni, ho visto un suo 
messaggio qui proprio in questi giorni e mi fa anche piacere che sia 
tornato (sperando che non ci ri-rompiamo gli zebedei a vicenda).
Welcome back to Xxxxxx.


 Decisamente al monitor... :-)
beh però..... anche il post-it non scherza.
Quel modo di utilizzare sudo a me continua a non convincere.
Mi sembra come quella di dover chiedere al firewall administrator di 
aprire le porte una a una, dopo avermi già aperto la porta 22.
A quel punto:
for i in $(seq "some-range"); do
 
  ssh -L $(($i + 1000)):127.0.0.1:$i user@server
done
e non ho più bisogno di lui.


 due che
le uniche due *persone* che


 e non ho più bisogno di lui.
...non saprei se questo funziona.
bye,
-- 
piergiorgio

 per quanto è rischioso.
E' proprio qui che volevo arrivare. Lo so che è osceno. E il punto è che 
questo strumento può rivelarsi un boomerang se viene usato per innalzare 
il livello di sicurezza.
Poi sono d'accordo sul resto.


 done
Mi permetto di perfezionarlo...
for ((i=$portainizio; i<=$portafine; i++)); do
	SSHARG="$SSHARG -L $i:127.0.0.1:$i
done
ssh -l $user $SSHARG server
Non è meglio? :-)


 e non ho più bisogno di lui.
Finche' non devi usare qualcosa non tcp-based...

 for ((i=$portainizio; i<=$portafine; i++)); do
cavolo.... mi sfuggiva del tutto l'esistenza di '++' nella bash.


 Non è meglio? :-)
e no ... mi sfuggiva una cosa ben più importante, che un collega mi 
chiedeva l'altro giorno.. e cioè: tu con una singola sessione "forwardi" 
più porte.
Grazie mille!




Antani, che intendi dire??
mi riferisco più all'italiano che all'informatica, più negazioni possono 
affermare, quindi mi sfugge cosa scrivi.


 affermare, quindi mi sfugge cosa scrivi.
Ok, era piu' che altro una battuta...
Tu hai detto: 
"...allora posso fare questo:
<forward di n porte tcp>
e non ho piu' bisogno di lui" (lui == amministratore del firewall)
Io ho detto: non hai piu' bisogno di lui fintanto che usi applicazioni tcp;
quando poi hai bisogno di usare un'applicazione che non va su tcp, allora
probabilmente avrai ancora bisogno di lui.
(si', potevo starmene zitto)

 Antani, che intendi dire??
Che non puoi incapsulare udp in un tunnel ssh, afaik.

 Antani, che intendi dire??
Bellissima, una supercazzola eseguita nel nome stesso.

 produce il postit?
Direi ai produttori della penna.
Ciao,
ScriptJus 

 alias pippo='echo miapassword | sudo -S'
Eh, ma che palle.
Puoi anche decidere di non mettere una password al tuo utente,
neppure a root e di mettere come init /bin/bash.
Ma sono scelte tue, non è lo strumento ad avere problemi.
-- 
ValeRyo
CBR600F "Cerbero" - 
http://www.slimmit.com/go.asp?6YT
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 root e di mettere come init /bin/bash. 
non hai capito una minchia. La password di sudo non aggiunge valore alla 
sicurezza, anzi rischia di toglierne. Lo scopo di quella feature è un 
altro.


 č un altro.
La password di sudo ha lo stesso valore della password di root:
la inserisci e sai che stai per fare qualcosa di pericoloso.
In piů con sudo puoi decidere di far fare solo determinate cose
ad un utente, mentre dandogli la password di root no.
Per rendere pericolosa la cosa, nel tuo esempio, hai dovuto
1) scrivere la tua password in un file
2) rendere il file leggibile da tutti
3) rendere la dir che contiene il file leggibile da tutti
Se fai una cosa del genere l'amministratore dovrebbe toglierti
il permesso anche di fare echo, altro che sudo.


 chiaro che puoi fare quello che ti pare, no?
Relativamente, ssh richiede che i permessi sui file siano stringenti.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com