[RISOLTO]Autostart degli scripts

[conraid]

... infatti sto usando un kernel nuovo su un portatile! .... il timeout si regola in quale file??

rc.udev... ma attento

[N1cuz]

... Grazie mille conraid, con un pò di pazienza sono riuscito a configurare il timeout di udev in maniera soddisfacente... per quanto riguarda lo script d'avvio credo che sia una bella bega perchè non so se basta "chmod +x nome_script.sh" in quanto i demoni per la connessione e gli altri script commentati in rc.M mandano in esecuzione processi che devono essere lanciati da root e questo comando è sufficiente per poter eseguire tutti i processi lanciati con lo script???

[Mario Vanoni]

... Grazie mille conraid, con un pò di pazienza sono riuscito a configurare il timeout di udev in maniera soddisfacente... per quanto riguarda lo script d'avvio credo che sia una bella bega perchè non so se basta "chmod +x nome_script.sh" in quanto i demoni per la connessione e gli altri script commentati in rc.M mandano in esecuzione processi che devono essere lanciati da root e questo comando è sufficiente per poter eseguire tutti i processi lanciati con lo script???

Non ho seguito questo thread.

Da Super-User (root):
chown root:root nome_script.sh
e sei vuoi essere proprio cattivo
chmod 4700 nome_script.sh

se non viene eseguito,
contiene qualche errore di sintassi.

[N1cuz]

... errori non li contiene perchè lanciando lo script da terminale viene eseguito... è nell'esecuzione automatica all'avvio il problema, adesso provo a seguire il tuo consiglio... c'è modo di far mandare un segnale dal sistema o di mostrare l'output in un terminale durante l'esecuzione??

[Mario Vanoni]

... errori non li contiene perchè lanciando lo script da terminale viene eseguito... è nell'esecuzione automatica all'avvio il problema, adesso provo a seguire il tuo consiglio... c'è modo di far mandare un segnale dal sistema o di mostrare l'output in un terminale durante l'esecuzione??

NO, ma lo puoi protocollare.

Nel tuo script:

#!/bin/sh
PROTOCOLLO='/var/log/protocollo' # o dove ti piace
#> ${PROTOCOLLO}
togli il cancetto se vuoi azzerare ogni volta,
altrimenti si aggiunge ai protocolli vecchi.
> echo '--- START ---' >> ${PROTOCOLLO}

ad ogni comando_xyz nel tuo script aggiungi a fine riga, con spazio,
comando_xyz >> ${PROTOCOLLO} 2>&1

Spiegazione: >> manda lo stdout, 2>&1 anche lo stderr, insomma tutto.

[masalapianta]

chown root:root nome_script.sh
e sei vuoi essere proprio cattivo
chmod 4700 nome_script.sh

il setuid e' inutile in caso di script (funziona solo con i binari)

[davide77]

Io lancerei gli script con sudo, non so se ci sono controindicazioni; il vantaggio è che puoi selezionare gli utenti e i comandi che possono eseguire come root.

Per usare sudo lanci da root visudo e aggiungi una riga come questa (al posto di utente ci metti il tuo):

Codice: Seleziona tutto

utente	ALL=(ALL)	NOPASSWD: ALL

Per cominciare lasci eseguire al tuo utente qualunque comando con "sudo comando". Quando hai sistemato l'avvio come ti piace puoi guardare il manuale di sudo e permettere solo i comandi che servono per fare l'avvio.

[conraid]

... Grazie mille conraid, con un pò di pazienza sono riuscito a configurare il timeout di udev in maniera soddisfacente... per quanto riguarda lo script d'avvio credo che sia una bella bega perchè non so se basta "chmod +x nome_script.sh" in quanto i demoni per la connessione e gli altri script commentati in rc.M mandano in esecuzione processi che devono essere lanciati da root e questo comando è sufficiente per poter eseguire tutti i processi lanciati con lo script???

Ma di quale script di avvio parli?
Tieni presente che non puoi fare un file, dargli i permessi e aspettare che magicamente si avvia, ma lo devi lanciare.
E se è un tuo script il posto giusto per lanciarlo è dentro rc.local (al quale dovrai dare i permessi di esecuzione)

[Mario Vanoni]

chown root:root nome_script.sh
e sei vuoi essere proprio cattivo
chmod 4700 nome_script.sh

il setuid e' inutile in caso di script (funziona solo con i binari)

FALSO

cd /
find . -perm 4700 -exec file {} \;

nel mio sistema ho 11 volte
./path/nome: setuid Bourne shell script text executable

OK, script per mio uso personale

[conraid]

chown root:root nome_script.sh
e sei vuoi essere proprio cattivo
chmod 4700 nome_script.sh

il setuid e' inutile in caso di script (funziona solo con i binari)

FALSO

cd /
find . -perm 4700 -exec file {} \;

nel mio sistema ho 11 volte
./path/nome: setuid Bourne shell script text executable

OK, script per mio uso personale

Il fatto che tu ce l'abbia non significa che funzioni.
Se per esempio hai uno script simili

Codice: Seleziona tutto

#!/bin/sh
/usr/sbin/iptables -L -n

hai voglia a mettere il bit suid allo script, avrai sempre

Codice: Seleziona tutto

Permission denied (you must be root)

Se poi il bit suid lo usi per altro visto che tanto tu sei sempre root, allora non so

Se invece metti il bit suid a iptables, allora anche l'utente puoi eseguirlo.
Questo è quel che intendeva masalapianta, almeno credo

[Mario Vanoni]

Caro Conraid

sono script per far partire il sistema,
per quanto abbia capito.

Se non eseguono, permission sbagliata.

Lo SUID su root, il sistema parte sempre quale root,
magari agevola il tutto.

Ho detto FALSO perche` anche uno sh puo` essere SUID,
non solo i binari/compilati!

[conraid]

Caro Conraid

sono script per far partire il sistema,
per quanto abbia capito.

Se non eseguono, permission sbagliata.

Lo SUID su root, il sistema parte sempre quale root,
magari agevola il tutto.

Ho detto FALSO perche` anche uno sh puo` essere SUID,
non solo i binari/compilati!

Ma non gli serve a niente essere suid root, tanto non potrà mai avere i permessi di root (tipo accedere all'hardware, etc) come succederebbe ad un binario, se lanciato da un utente.
Quindi sì, puoi averlo, come io posso avere le ali, ma tanto se non posso volare che ci faccio?

Se non eseguono c'è qualche errore, o come penso, non specificati da nessuna parte. Permission sbagliata può darsi, ma non risolve certo con un bit suid ad uno script.
Che poi non ho ancora capito che script sia, nel senso di come è fatto

[Mario Vanoni]

Caro Conraid

sono script per far partire il sistema,
per quanto abbia capito.

Se non eseguono, permission sbagliata.

Lo SUID su root, il sistema parte sempre quale root,
magari agevola il tutto.

Ho detto FALSO perche` anche uno sh puo` essere SUID,
non solo i binari/compilati!

Ma non gli serve a niente essere suid root, tanto non potrà mai avere i permessi di root (tipo accedere all'hardware, etc) come succederebbe ad un binario, se lanciato da un utente.
Quindi sì, puoi averlo, come io posso avere le ali, ma tanto se non posso volare che ci faccio?

Se non eseguono c'è qualche errore, o come penso, non specificati da nessuna parte. Permission sbagliata può darsi, ma non risolve certo con un bit suid ad uno script.
Che poi non ho ancora capito che script sia, nel senso di come è fatto

Guarda che io ho detto che un sh puo` essere SUID, niente altro!
Sh SUID viaggiano da anni in ditta, Slackware 10.1, kernel 2.4.31.

Se Nicola ha messo l'owner dello script non root, ha fatto un errore.
Se immette un protocollo, forse si trova il groppo.

[conraid]

Guarda che io ho detto che un sh puo` essere SUID, niente altro!
Sh SUID viaggiano da anni in ditta, Slackware 10.1, kernel 2.4.31.

Sotto linux i suid agli script vengono ignorati

[masalapianta]

chown root:root nome_script.sh
e sei vuoi essere proprio cattivo
chmod 4700 nome_script.sh

il setuid e' inutile in caso di script (funziona solo con i binari)

FALSO

invece e' vero, studia o fattene una ragione:

burp:/tmp# chmod 4755 ilsetuidnonfunzionacongliscript.sh
burp:/tmp# cat ilsetuidnonfunzionacongliscript.sh
#!/bin/sh

cat /etc/shadow
burp:/tmp# su ale
burp:/tmp$ id
uid=1003(ale) gid=1002(ale) gruppi=1002(ale)
burp:/tmp$ ./ilsetuidnonfunzionacongliscript.sh
cat: /etc/shadow: Permission denied
burp:/tmp$ ls -al ilsetuidnonfunzionacongliscript.sh
-rwsr-xr-x 1 root root 27 2008-10-17 23:31 ilsetuidnonfunzionacongliscript.sh
burp:/tmp$

cd /
find . -perm 4700 -exec file {} \;

nel mio sistema ho 11 volte
./path/nome: setuid Bourne shell script text executable

e quindi? il fatto che tu abbia degli script setuid non significa che il setuid funzioni come funziona con i binari
(difatti se rileggi la mia frase che hai riportato io non ho detto che il setuid con gli script non e' impostabile
ma che e' inutile perche' funziona solo con i binari)