ripristinati permessi inaspettatamente

[conraid]

Ho appena provato lo fa anche con tgz.

prova a dare i comandi a mano
xz e tar intendo

[conraid]

ho provato
è tar che fa questa cosa

[conraid]

ho provato
è tar che fa questa cosa

no, correggo
non è tar, se creo io un archivio tar è tutto ok, se lo eseguo su un pacchetto slackware allora da quel comportamento

[ulisse89]

Mi sono corretto: cambia proprietario e gruppo di appartenenza del file no? Anche a te succede così?

[ulisse89]

Allora l'errore dev'essere nello script di explodepkg e io l'unica cosa che vedo inerente a permessi di file etc è il comando `umask 000` alla fine.

[conraid]

Mi sono corretto: cambia proprietario e gruppo di appartenenza del file no? Anche a te succede così?

metto un esempio così di capisce

Codice: Seleziona tutto

# ls -l
totale 4,0K
drwxrwxrwx 2 conraid users 4,0K 2009-11-06 18:00 xz
# cd xz
# ls -l
totale 1,7M
-rw-r--r-- 1 conraid users 1,7M 2008-11-21 03:20 alpine-2.00-i486-1.txz
-rw-r--r-- 1 root    root   427 2009-11-06 17:49 prova.tgz
# tar -xvf alpine-2.00-i486-1.txz
./
usr/
usr/doc/
usr/doc/pinepgp-0.18.0/
usr/doc/pinepgp-0.18.0/README
usr/doc/pinepgp-0.18.0/COPYING
usr/doc/alpine-2.00/
usr/doc/alpine-2.00/README
usr/doc/alpine-2.00/LICENSE
usr/doc/alpine-2.00/VERSION
usr/doc/alpine-2.00/tech-notes.txt.gz
usr/doc/alpine-2.00/NOTICE
usr/doc/alpine-2.00/mailcap.unx
usr/doc/alpine-2.00/mime.types
usr/doc/alpine-2.00/brochure.txt
usr/share/
usr/bin/
usr/bin/alpine
usr/bin/rpdump
usr/bin/pinepgpgpg-install
usr/bin/pico
usr/bin/pilot
usr/bin/rpload
usr/bin/pinegpg
usr/man/
usr/man/man1/
usr/man/man1/rpdump.1.gz
usr/man/man1/pilot.1.gz
usr/man/man1/pico.1.gz
usr/man/man1/alpine.1.gz
usr/man/man1/rpload.1.gz
etc/
etc/pine.conf.new
install/
install/slack-desc
install/doinst.sh
# ls -l
totale 1,7M
-rw-r--r-- 1 conraid users 1,7M 2008-11-21 03:20 alpine-2.00-i486-1.txz
drwxr-xr-x 2 root    root  4,0K 2008-11-21 03:20 etc
drwxr-xr-x 2 root    root  4,0K 2008-11-21 03:20 install
-rw-r--r-- 1 root    root   427 2009-11-06 17:49 prova.tgz
drwxr-xr-x 6 root    root  4,0K 2008-11-21 03:20 usr
# cd ..
# ls -l
totale 4,0K
drwxr-xr-x 5 root root 4,0K 2009-11-06 18:01 xz

come vedi la directory xz da conraid:users 777 è passata a root:root 755

Codice: Seleziona tutto

# chmod 777 xz
# chown conraid:users xz
# ls -l
totale 4,0K
drwxrwxrwx 5 conraid users 4,0K 2009-11-06 18:01 xz
# cd xz
# cd ..
# ls -l
totale 4,0K
drwxrwxrwx 5 conraid users 4,0K 2009-11-06 18:04 xz
# tar -xvf prova.tgz
test.sh
test.sh~

se faccio la stessa cosa con un tgz creato da me con "tar czf " i permessi rimangono invariati

non penso sia un comportamento corretto

andrebbero fatte alcune prove, confermata la cosa, e chi ha dimestichezza con l'inglese scrivere a Pat o su LQ

[conraid]

Allora l'errore dev'essere nello script di explodepkg e io l'unica cosa che vedo inerente a permessi di file etc è il comando `umask 000` alla fine.

no, prova solamente con tar, senza usare explodepkg e guarda

sembra un problema del file compresso, ma non saprei cosa

[raffaele181188]

Io penso che la risposta sia in tar, uno dei peggiori e più assurdi programmi della storia
E' comunque uno dei motivi per cui non mi piace usare root per fare i pacchetti. Da utente normale tutte queste cose non succederebbero. Ad ogni buon conto questo è il mio esempio, ma non riesco ad afferrare il vostro problema perchè da me la directory corrente non cambia proprietario

Codice: Seleziona tutto

$ ls -al
drwxr-xr-x 2 raffaele users   4096 2009-11-06 18:39 ./
drwxr-xr-x 6 raffaele users   4096 2009-11-06 18:37 ../
-rw-r--r-- 1 raffaele users 343002 2009-11-06 18:37 kmix.tar.lzma
$ su
# tar xzf kmix.tar.lzma
# ls -al
drwxr-xr-x 3 raffaele users   4096 2009-11-06 18:40 .
drwxr-xr-x 6 raffaele users   4096 2009-11-06 18:37 ..
drwxr-xr-x 8 raffaele users   4096 2009-11-02 19:51 kmix
-rw-r--r-- 1 raffaele users 343002 2009-11-06 18:37 kmix.tar.lzma

Comunque in questo frammento di conraid

Codice: Seleziona tutto

# tar -xvf alpine-2.00-i486-1.txz
./
usr/
usr/doc/
... eccetera ...

vedo che tar, tra i file estratti, considera pure un ./ Potrebbe essere questo il problema? Appartenendo a root:root e dato il comportamento assurdo di tar, che non avvisa delle sovrascritture... Può essere?

[raffaele181188]

UPDATE: Il mio esempio ovviamente non è azzeccato perchè i file nell'archivio sono di raffaele e tar, eseguito da root, lascia inalterata la proprietà di file e directory.

Comunque può darsi che il segreto sia qui

Codice: Seleziona tutto

$ mkdir test
$ touch test/prova.txt
$ tar cf archivio.tar test
$ tar tvf archivio.tar
drwxr-xr-x raffaele/users    0 2009-11-06 19:18 test/
-rw-r--r-- raffaele/users    0 2009-11-06 19:18 test/prova.txt
$ cd test/
$ tar cf ../archivio.tar .
$ tar tvf ../archivio.tar
drwxr-xr-x raffaele/users    0 2009-11-06 19:18 ./
-rw-r--r-- raffaele/users    0 2009-11-06 19:18 ./prova.txt

Quindi in sostanza, per me, quel ./ che appartiene a root:root poichè makepkg crea l'archivio eseguendo tar nella directory corrente

[ulisse89]

se faccio la stessa cosa con un tgz creato da me con "tar czf " i permessi rimangono invariati

non penso sia un comportamento corretto

Identico comportamento sulla mia slackware. Ho fatto le stesse tue prove.

[conraid]

Pat ha risposto

Well, I'm not really sure that I follow your "test". You don't
actually show using tar czf, or using explodepkg. However, it is
normal for a package to change the permissions of every included
directory. That means "/", too, so you have to be sure that all the
directories in the package have the correct perms/ownership.

chi me lo spiega?

[ulisse89]

Ho capito. Praticamente dato che nel pacchetto tgz o txz che sia, è impostato che "/" (che è la directory corrente quando tar spacchetta) abbia proprietario root e gruppo root, allora tar imposta la stessa ownership anche alla directory corrente.
Non credo di essermi spiegato benissimo, però spero che tu abbia capito.

[raffaele181188]

Ecco un test un po' più significativo, eseguito in una directory empty creata all'uopo

Codice: Seleziona tutto

bash-3.1$ mkdir -p foo/bar
bash-3.1$ cd foo
bash-3.1$ su

bash-3.1# chown -R root:root .
bash-3.1# tar cvf ../archive.tar .
./
./bar
bash-3.1# cd ..
bash-3.1# ls -ld .
drwxr-xr-x 3 raffaele users 4096 2009-11-06 20:16 .
bash-3.1# tar xf archive.tar
bash-3.1# ls -ld .
drwxr-xr-x 4 root root 4096 2009-11-06 20:16 .

Questi comandi sono la sequenza tipica per la creazione di un pacchetto. Come si può vedere, l'estrazione dell'archivio provoca il cambio di proprietà della directory "."

Offtopic: /sbin/explodepkg si può eseguire anche da utente normale, mi pare, solo che non è nel PATH ovviamente

[ulisse89]

Infatti tu prima di creare l'archivio imposti le ownership, in tal modo l'archivio se le "ricorda", e quando tar spacchetta le imposta anche alla directory corrente. Per questo a me e conraid che avevamo provato a creare un archivio di prova (senza impostare le ownership alla directory radice dell'archvio ), una volta che spacchettavamo non cambiava le ownership della directory. Invece con i pacchetti in cui ovviamente la directory radice ha root:root come ownership, il tar e di conseguenza l'explodepkg cambia l'ownership della directory in cui lo scompatti.

[conraid]

ok capito, ma allora perché per alcuni pacchetti cambia la home?

io non ho mai installato chrome e quindi non so, ma tutto il discorso era partito da li, forse c'è un "problema" simile nel pacchetto o nel build?