Newsgroup: it.comp.lang.c++
Titolo: Come mai? Urgente!!

ho un piccolo problema per il quale, spero, mi potrete aiutare.
Ho scritto un programmino di prova in C++, l'ho compilato e fino a lě č
andato
tutto bene. Quando perň sono arrivato a lanciarlo, mi č arrivato questo
messaggio:
"bash: code: command not found".
Questo mi accade anche con i programmi in C, la compilazione va a buon
fine, ma quando vado ad eseguire, mi arriva quel messaggio.
Qualcuno sa a cosa puň essere dovuto questo malfunzionamento?
Saluto e la ringrazio anticipatamente.
Del Mutolo Nicola


Solo un dubbio: hai fatto "./a.out" ?
Comunque questo tipo di domande (come avviare un programma)
andrebbero poste in newsgroup piů specifici.
Manlio Perillo

 wrote in message
news:8utogg$f3r$2...@nslave2.tin.it...


andrebbero poste in newsgroup più specifici.
Si, it.comp.os.linux.iniziare credo.
Il Ghenio
-----------
LOVELY SARA
Dal lunedi'al venerdi'su Italia Uno alle 8:10
Non perdetevelo...
-----------



 PATH=$HOME/bin:./:$PATH
Semplicemente osceno!!!!
La directory corrente per ovvi motivi *non* va inclusa nel path!
ciao
Kronos
-- 
Home: 
http://kronoz.tsx.org
"Another Brick in the Wall part 2"
We don't need no pull-down-menus
We don't need no rescaled fonts
No dark icons in the corner
Hackers, leave those Macs alone.
Hey! Hackers! Leave them Macs alone!
All in all it's just another WIMP up for sale
All in all you're just another WIMP up for the sale.

La directory corrente per ovvi motivi *non* va inclusa nel path!
Quali sono gli "ovvi" motivi ?
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff


Forse allude alla vulnerabilità del sistema nei confronti dei troiani:
includere la directory corrente nella PATH aumenta tale vulnerabilità.
Domenico Barra

includere la directory corrente nella PATH aumenta tale vulnerabilità.
O forse credeva che il path di ricerca comprendesse sempre la
directory corrente come in DOS...
Ma quali sarebbero questi maggiori rischi di vulnerabilita' ?
In fondo se lancio un trojan con il mio utente lui puo' gia'
fare tutto quello che posso fare io... a che gli serve fingersi
un comando di sistema ? se deve fare qualcosa con i miei permessi
puo' farlo direttamente... o no ?


 
Ti è mai capitato di digitare 'grpe', invece di 'grep'?  O 'la' invece di
'ls'? Ora immagina che qualcuno metta un eseguibile di nome 'grpe' in
/tmp. In sostanza avere '.' in PATH aumenta il rischio che si possa per
errore eseguire programmi collocati in directory non note e non di
sistema.
Max

sistema.
O ancora peggio, pensa se qualcuno mette un troiano di nome "cd" nella
dir corrente...

 dir corrente...
Non succederebbe *assolutamente* niente. Prova un po' a spiegare
perche'.
Pero' uno script chiamato ls che invece esegue "rm -rf /" qualche guasto
lo produrrebbe.
Ciao,
Nicola

Una parziale contromisura e' mettere il "." in fondo al path. Ed in ogni
caso, se magari e' opportuno evitare che root abbia . nel path, per un
utente non privilegiato non mi sembra un grosso problema. Probabilmente
si riesce anche a scrivere un .<lamiashellpreferita>rc che mette il .
solo per le sessioni interattive.
Ciao,
Nicola



Ho fatto qualche ricerca ed effettivamente si introduce qualche
rischio per root che e' normalmente l'utente che va in giro a
lanciare programmi da directory altrui.
Per utenti diversi da root mi sembra semplicemente paranoia (in
fondo chi e' riuscito a mettere un file nella directory di un
utente se non mi sbaglio avrebbe gia' potuto, ad esempio,
eliminare -qualunque- file in quella directory).
Ovviamente per utenti di servizio (non umani) il vantaggio di
avere "." nel path e' nullo e solo fonte di potenziali
problemi per gli script.
Questo mi porta a pensare che chi ha fatto il primo commento
su quanto fosse assurdo mettere "." nel path e quanto ne fossero
ovvie le ragioni non capisca nulla di unix.


 ovvie le ragioni non capisca nulla di unix.
Non e' vero :-)
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it
Murphy's law: "Anything that can go wr
/bin/fortune: segmentation fault - core dumped

 Non e' vero :-)
Non e' vero che mi porta a pensarlo ?
Andrea
--
----------------------------------------------------------------
 <\___/>  Andrea        email: agriff at tin dot it
 / . . \  "6502"          irc: _6502_@EFNET#italia
(  (")  ) Griffini   homepage: 
http://www.netservers.com/~agriff
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 quello che lo si vuole far diventare.
La versione Posix del comando su differenzia quando lo si lancia o meno
con primo argomento "-". Se il primo argomento e' "-" la shell e'
eseguita come una shell di login, altrimenti come shell normale. Quali
script vengano eseguiti all'inizializzazione dipende dal tipo di shell.
Ciao,
Nicola

lo produrrebbe.
E cosa cambia da "cd" ?

 E cosa cambia da "cd" ?
Che ls *e'* un eseguibile esterno.
Ciao,
Nicola

non vorrei interrompere la vostra idilliaca conversazione, ma se
poteste continuarla in privato sarebbe meglio, visto che č OT
esattamente come i msg su windows.
Senza offesa, naturalmente :)

l'environment di un processo "antenato".
OK, ho capito; e dire che quando avevo letto il perchč non mettere ./
nella path avevo trovato proprio l'esempio di cd...
Anto

 Senza offesa, naturalmente :)
Hai ragione. E' anche vero pero' che chi e' arrivato a leggere il
tredicesimo livello di messaggi si aspetta probabilmente la fine del
racconto :-)
Ciao,
Nicola

 ovvie le ragioni non capisca nulla di unix.
lavoro su linux da piu' di un anno e ho un po' di esperienza su solaris
e penso di poter dire che qualcosa capisco
ciao
Kronos
-- 
Home: 
http://kronoz.tsx.org
Il coraggio non mi manca.
E' la paura che mi frega...

e penso di poter dire che qualcosa capisco
Mi scuso pubblicamente se e' suonato offensivo il "non capisce
nulla di unix" ma queste ragioni non apparivano assolutamente
"ovvie" a me.
Dopo essermi documentato sono giunto alla conclusione che si
tratta di un problema potenziale per l'utente root ma che il
rischio sia marginale e discutibile nel caso di altri utenti.
Inoltre se realmente uno script girando con i privilegi di un
utente comune potesse provocare "grossi danni" al sistema
credo che quel sistema dovrebbe rivedere buona parte
dell'approccio al problema della sicurezza.


 dell'approccio al problema della sicurezza.
gravi, non mortali
e forse mi sono espresso male: tutte le directory ed i file vitali sono
fuori dalla portata dell'utente non privilegiato
tuttavia i dati dell'utente e degli utenti appartenenti allo stesso
gruppo sono a rischio di cancellazione
ciao
Kronos
-- 
Home: 
http://kronoz.tsx.org
I went to God just to see
And I was looking at me
Saw heaven and hell were lies
When I'm God everyone dies