ripristinati permessi inaspettatamente

[conraid]

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?

ho visto adesso questa parte, e sembra proprio questo il "problema", ma makepkg funziona così

va beh, ora lo sappiamo (magari per molti era normale e banale), bisogna tenerne conto nella creazione di pacchetto e nell'uso di tar/explodepkg

[raffaele181188]

UPDATE: Non avevo visto gli ultimi interventi Mi sembra comunque una cosa da segnalare a Pat, anche perchè io ho sempre ritenuto assurdo il comportamento di makepkg, oltre che favorevole agli errori. I "cd" negli script sono roba che scotta, non vedo perchè non accettare due parametri

Il punto è che si può creare un archivio in due modi a seconda della directory di lavoro. Makepkg usa la seconda versione, e le cose cambiano radicalmente perchè a questo punto nell'archivio c'è anche il file "." con relativo proprietario che sovrascrive quello della directory al momento dell'estrazione. Nelle vostre prove questo non accadeva perchè creavate l'archivio nel primo modo, cioè dall'esterno della directory target

Codice: Seleziona tutto

tar cvf archivio.tar directory
tar cvf ../archivio.tar .

Allego uno script di test. Va eseguito necessariamente da root, perchè da utente normale tar, al momento dell'estrazione, cambia la proprietà di quello che c'è nell'archivio. Modificate come vi pare il valore di OWNER alla prima riga

Codice: Seleziona tutto

#!/bin/sh
# a group your user belongs to. Needed for test
GROUP=plugdev
mkdir -p test/foo/bar
set -e
# cd to our working directory to prevent name collisions
cd test/
echo "Working/Target directory:"
pwd
# change group ownership of foo/ and foo/bar
# Simulate package creation
cd foo
chgrp -R $GROUP .
tar cf ../archive.tar .
cd ..
# Now we are in test/
echo "Current directory belongs to"
ls -ld . | awk '{print$4;}'
tar xf archive.tar
echo "After extracting archive.tar, current directory group owner is"
ls -ld . | awk '{print$4;}'

Per quanto riguarda Chrome, la cosa strana è che al riavvio si trovano i permessi sistemati

[ulisse89]

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?

Infatti io ero riandato a vedere i problemi precedenti e nel caso del mio che avevo aperto il thread era proprio l'explodepkg ma quello di questo link
viewtopic.php?f=1&t=29824 per me è lo stesso.
Se noti nell slackbuild c'è il comando

Codice: Seleziona tutto

ar -x $CWD/google-chrome-unstable_current_i386.deb

che estrare un archivio e se CWD era impostato nella home gli cambiava i permessi della home.

[ulisse89]

Il punto è che si può creare un archivio in due modi a seconda della directory di lavoro. Makepkg usa la seconda versione, e le cose cambiano radicalmente perchè a questo punto nell'archivio c'è anche il file "." con relativo proprietario che sovrascrive quello della directory al momento dell'estrazione. Nelle vostre prove questo non accadeva perchè creavate l'archivio nel primo modo, cioè dall'esterno della directory target

Codice: Seleziona tutto

tar cvf archivio.tar directory
tar cvf ../archivio.tar .

Hai ragione, ho fatto le prove ed è così. Quindi tu dici che basterebbe fare usare a makepkg il tar da fuori l'archivio?

[raffaele181188]

Sì, e si avrebbe anche un comando più intuitivo e leggibile. Inoltre si abbasserebbe la probabilità di errori negli script