slacky.eu

usr/local ha 755 (creato da aaa_base)

il mio script scarica metodicamente i pacchetti (da un mirror... 1Mbyte al secondo non ci dovrei mettere molto a finire) e da un tar tJvf |grep rwxrwxrwx

Ciao
01

ZeroUno ha scritto:usr/local ha 755 (creato da aaa_base)

il mio script scarica metodicamente i pacchetti (da un mirror... 1Mbyte al secondo non ci dovrei mettere molto a finire) e da un tar tJvf |grep rwxrwxrwx

Ciao
01

Allora la smetto di controllarli uno ad uno.
Quando hai finito gli cambiamo/cambio la versione e poi quando avrò tempo ricompilo/ricompiliamo tutto.
Più che altro sono dei giorni del cavolo perchè ho un esame. Tra due giorni mi metterò a riparare al danno.
Prima mi piacerebbe capire cosa è successo. Più che altro per non ripetere.

Grazie a tutti comunque e soprattutto a chi ha aperto il topic e a chi si sta sbattendo per rimediare ai miei errori.

EDIT: Fino a freecol della lista di ZeroUno gli ho già cambiato la versione in "ripristina permessi-ricompilare", così almeno si evita di farli scaricare da qualche inconsapevole.

Reilly ha scritto:P.S.: Anche i pacchetti `mozilla-firefox-it-3.5.6-i686-1sl.txz' e
`mozilla-thunderbird-it-3.0-i686-1sl.txz' hanno di questi problemi...
cioe', settano la struttura di `/usr' in 0777 (!!!!)... ma che
succede?

Strano. Dovrebbe trattarsi degli stessi SlackBuild usati da Pat.
Io li uso sempre (quelli della current) per ricompilare da sorgente Firefox3 e Thunderbird3 e non mi hanno mai alterato i permessi.

non e' che hai una umask per l'utente con cui ricompili i pacchetti settata in .bashrc o .bash_profile come 000 (022 sarebbe quella di default definita in /etc/profile)?

Visto che non tutti coloro che
scaricano i pacchetti leggono
anche il forum (vedi anche i
download dall'estero) penso
sia utile pubblicare una sorta di
avviso in home page in modo
da permettere ad un numero maggiore
di utenti di verificare se ha installato
i pacchetti difettosi e reinstallare
i pacchetti ricompilati.

phobos3576 ha scritto:
Reilly ha scritto:P.S.: Anche i pacchetti `mozilla-firefox-it-3.5.6-i686-1sl.txz' e
`mozilla-thunderbird-it-3.0-i686-1sl.txz' hanno di questi problemi...
cioe', settano la struttura di `/usr' in 0777 (!!!!)... ma che
succede?
Strano. Dovrebbe trattarsi degli stessi SlackBuild usati da Pat.
Io li uso sempre (quelli della current) per ricompilare da sorgente Firefox3 e Thunderbird3 e non mi hanno mai alterato i permessi.

Sicuramente il problema sta nella mia macchina e non nello SlackBuild. Perchè tutti quelli segnalati sono stati compilati da me.
Resta da capire cosa provoca questo errore, io non riesco a capire.

non e' che hai una umask per l'utente con cui ricompili i pacchetti settata in .bashrc o .bash_profile come 000 (022 sarebbe quella di default definita in /etc/profile)?

Il file .bashrc non c'è, bash_profile non setta un umask diversa e in /etc/profile è tutto regolare.
Comunque io quando lancio gli SlackBuild sono root (come tutti poi) cosa intendi con "'utente che usi quando ricompili"?

Visto che non tutti coloro che
scaricano i pacchetti leggono
anche il forum (vedi anche i
download dall'estero) penso
sia utile pubblicare una sorta di
avviso in home page in modo
da permettere ad un numero maggiore
di utenti di verificare se ha installato
i pacchetti difettosi e reinstallare
i pacchetti ricompilati.

Giusto. Credo lo possa fare uno dello staff o l'amministratore.

ZeroUno ha scritto:Però è strano perchè quando compili lavori tipicamente in /tmp

Ho lanciato uno script per cercare i pacchetti bacati e per ora ho trovato questi:

artha-0.9.1-i686-1uls.txz
tabble-0.40-i486-4sl.txz
codeblocks-8.02-i486-5as.txz
fpc-2.2.4-i386-2ld.txz
ginac-1.5.3-i486-1pfb.txz
lemon-20091027-i486-1an.txz
littlewizard-1.2.2-i486-3bj.txz
numeric-24.2-i486-4as.txz
pd-0.42.5-i486-1as.txz
splint-3.1.2-i486-3as.txz
treecc-0.3.10-i486-4as.txz
valgrind-3.5.0-i486-2as.txz
wxpython-2.8.10.1-i686-3pv.txz
xdelta-1.1.4-i486-4gi.txz
freecol-0.8.4-i486-2dav.txz
di 148 analizzati

Ciao
01

Io ho quella versione di codeblocks e sembra tutto a posto, almeno non ho file in /usr/bin, /usr/doc con permessi a 777. EDIT: scusa, hai ragione, codeblocks ha i permessi sballati.
Consiglio a tutti di dare questo comando da root:

Codice: Seleziona tutto

cd /
find -perm 777 -type d

Cerca tutte le directory sul sistema con i permessi settati a 777. Attualmente a me da:

Codice: Seleziona tutto

./usr/share/icons/gnome
./usr/share/icons/gnome/48x48

dopo aver rimosso codeblocks.

Bart ha scritto:Io ho quella versione di codeblocks e sembra tutto a posto, almeno non ho file in /usr/bin, /usr/doc con permessi a 777.

drwxrwxrwx root/root 0 2009-10-28 14:23 usr/

se poi successivamente hai installato altri pacchetti buoni te lo ha risistemato

Ciao
01

ZeroUno ha scritto:Però è strano perchè quando compili lavori tipicamente in /tmp

Ho lanciato uno script per cercare i pacchetti bacati e per ora ho trovato questi:

[CUT... CUT]
> valgrind-3.5.0-i486-2as.txz

Bravissimo!
Infatti `valgrind' e' un altro dei pacchetti incriminati!
Stavo per suggerirlo a Gohanz... ma poi ho visto che ci hai pensato tu.

A proposito, mi interessa mooolto il tuo script... non e' che me lo puoi
dare?
(stavo quasi per fare un controllo a tappeto, tanto io ho l'intero
repository di `slacky.eu' nel mio hard-disk... ma visto che adesso c'e'
il tuo script mi sembra inutile...)

phobos3576 ha scritto:
Strano. Dovrebbe trattarsi degli stessi SlackBuild usati da Pat.
Io li uso sempre (quelli della current) per ricompilare da sorgente Firefox3 e Thunderbird3 e non mi hanno mai alterato i permessi.

Ma infatti come avevo gia scritto tra parentesi la colpa non e' degli
`SlackBuild', ma di altro...

giberg ha scritto:Visto che non tutti coloro che
scaricano i pacchetti leggono
anche il forum (vedi anche i
download dall'estero) penso
sia utile pubblicare una sorta di
avviso in home page in modo
da permettere ad un numero maggiore
di utenti di verificare se ha installato
i pacchetti difettosi e reinstallare
i pacchetti ricompilati.

NO!
Ti prego, desistiamo dal fare una cosa del genere... cioe' se si usasse
un sistema di notifica *soltanto* per gli utenti di `slacky.eu'... allora
va bene... ma se invece la vogliamo rendere completamente pubblica, allora
no!
Qua... anzi la, quel maledetto `Google' ci osserva...
(mi sono gia quasi pentito di avere iniziato questo thread... quasi, quasi
mando a Loris una mail in modo da farlo desistere dal prendere una
iniziativa del genere... ripeto, Google ci osserva... )

Ciao

Reilly

Reilly hai fatto benissimo invece e un avviso non sarebbe fuori luogo.
Comunque per controllare se avete directory con i permessi a 777 date:

Codice: Seleziona tutto

#find / -perm 777 -type d

e per cercare invece i file

Codice: Seleziona tutto

#find / -perm 777 -type f

Ho terminato il controllo.
I pacchetti sono 100

ecco lo script

Codice: Seleziona tutto

#!/bin/bash
mkdir -p pkg
cat pkgs|grep txz$|while read F;do
  N=`basename $F`
  echo $N
  if [ ! -e pkg/$N.lst ];then
    wget -O - http://slack.isper.sk/pub/slackware-13.0/$F |tar tvJf - |grep -m 1 usr/ >pkg/$N.lst
  fi
done

scaricare il MANIFEST.md5 prima di lanciare lo script e dare

Codice: Seleziona tutto

cat MANIFEST.md5|awk '{print $2}'|grep t.z$ >pkgs

in pratica non scarico il pacchetto ma lo mando in pipe ad un tar, quindi aspetto che arriva la directory usr e termino il download (mi basta quello) e ne creo un file nella directory pkg.
La verifica la faccio commandline:

Codice: Seleziona tutto

( ls -tr|xargs -I '{}' grep -l rwxrwxrwx '{}'|sed 's/....$//' );echo di $(ls|wc -l) analizzati

Ciao
01

Bart ha scritto:
Reilly hai fatto benissimo invece e un avviso non sarebbe fuori luogo.

Certo, ma fare un avviso completamente pubblico potrebbe rovinare
la fama di robustezza e solidita' di una distribuzione Storica e
Granitica come Slackware... per non parlare di `slacky.eu' che
subirebbe anch'essa un enorme danno di immagine...

Gia da adesso i nostri post stanno scorrendo nel fiume malsano di
Google (non mi stanchero' mai di dirlo...)...

Comunque per controllare se avete directory con i permessi a 777 date:

#find / -perm 777 -type d

Ah, gia'...
Io infatti avevo scritto in modo quasi simile, cioe:

$find /usr -type d -perm 0777

Ma, invece, ho finito per scrivere nel mio post soltanto:

find /usr -perm 0777

Ma adesso vado a corregerlo...

Comunque, se si trovano directory in `/var' o in `/etc' ecc...
settate, che so' in 0775, in teoria - e dico in teoria - dovrebbe
essere "normale"...
trovare invece directory partendo dalla `/usr' o dalla `/opt' settate
in 0775, o peggio ancora in 0777... la si che *non e' normale*!

ZeroUno ha scritto: Ho terminato il controllo.
I pacchetti sono 100

Alla faccia!!

La verifica la faccio commandline:

( ls -tr|xargs -I '{}' grep -l rwxrwxrwx '{}'|sed 's/....$//' );echo di $(ls|wc -l) analizzati

Eh, eh... e' questa la stringa che mi interessa...
Grazie mille ZeroUno!

Comunque ragazzi, come ho gia detto tutto e' iniziato per via di
`wxpython' che aveva settata la dir `/usr/doc' in 0777, pero'
(forse) non me ne sarei potuto mai accorgermene se non avessi in
una parte del mio `/etc/profile' questa stringa qui:

if [[ ${EUID} == 0 ]] ; then
PS1='\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
fi

Infatti quando ho fatto:

$cd /usr

$ls

La dir `/usr/doc' mi e' apparsa di colore *VERDE*!!
Ed e' li che mi sono insospettito cominciando cosi' ad indagare...

Alla fine, il colore verde che e' bello e positivo... in questi casi
diventa uno spauracchio da far venire la pelle d'oca...
Insomma... qualcosa come la kryptonite per Superman... brrr...

Si dice in giro che quelli di Gentoo abbiano le righe che ho menzionato
sopra attive di default... beh... mi sa' che fanno bene...
(io ce li ho... )

Ciao!

Reilly

Security through obscurity semplicemente non funziona, un forum come il nostro dovrebbe saperlo più che bene

Per provare, ho ricompilato due pacchetti a caso che avevano questo problema (nextaw e libpaper).
Beh, li ha creati perfettamente senza permessi settati a 0777.
Il fatto è che tutti i pacchetti, o quasi, uppati da me sono corrotti, anche pacchetti che ho caricato pochi giorni fa. Non so cosa è cambiato ma oggi non fa più l'errore in questione. Da un lato era meglio se la mia macchina lo faceva ancora, così capivo meglio.

Da parte mia ho pensato che le directory /usr /usr/bin etc.. non vengono create manualmente nello SlackBuild ma dal make install che le crea in automatico (con mkdir credo). Il problema, in ogni caso, era che quando root creava una directory la creava con permessi settati a 777 (mentre doveva essere a 755).
Questo però non me lo so spiegare.

E' possibile che fosse stato impostato un alias che dava `mkdir -m 777` al posto di `mkdir` semplice. Da me però sicuramente no. E poi non spiegherebbe il fatto che oggi non c'è più.

puo' darsi che tu abbia fatto il source di un file shell che ti impostava l'umask a 000 (rimarrei di quella ipotesi): hai compilato tutti i pacchetti dalla solita shell?
se hai riavviato il pc/usato un'altra shell allora questa potrebbe non essere la spiegazione.
con "umask -p" vedi lo stato.
per l'utente mi riferivo al fatto che qualcuno (pochi, per fortuna) usa fakeroot.

slacky.eu

Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!

Re: Pacchetti slacky con permessi delle directory errati!