slacky.eu

Ciao a tutti,
negli slackbuild solitamente si decomprime i sorgenti, si setta il proprietario a root e poi si controllano i permessi.
Ora, se io faccio ciò per sqlite rilevo che esistono permessi "sbagliati" solo di tipo 600.
Ma se poi faccio ./configure --prefix=/usr && make && make install DESTDIR=/tmp/package-sqlite osservo che in /tmp/package-sqlite esistono: Ma le librerie non dovrebbero avere 755? In questo caso bisogna cambiare a 755 i permessi di tali liberie?
Io non ho mai visto in nessuno slackbuild ne' di PJV ne' di Slacky cambiare i permessi DOPO il make install.
Mi illuminate?
Vi ringrazio.

Quelli sopra erano symlink che vengono trattati correttamente da makepkg.
Resta il dubbio se make e make install possono installare file con permessi errati.

Slackware 12.0 aggiornata ad oggi.

Da http://www.linuxpackages.net scaricato l'ultimo sqlite.
installpkg sqlite*.tgz
I permessi sono o 0755 o 0644 per la libreria *.a.

pkgtool cancellato sqlite, nessuna traccia in /usr/lib

Scaricato dal sito officiale sqlite-3.5.7,
tar ..., poi esattamente quello che dici di aver fatto,
i permessi in /tmp/package-sqlite/usr/lib sono
esattamente come sopra, 0755 o 0644 per *.a.

L'unico che puo` risolvere il tuo problema sei _tu_!

Mario Vanoni

PS Ovviamente come utente root!

stan ha scritto:Quelli sopra erano symlink che vengono trattati correttamente da makepkg.
Resta il dubbio se make e make install possono installare file con permessi errati.

Quindi il tuo era un falso allarme . Per quanto riguarda i permessi, tutto dipende dal valore di umask, se per root è, come dovrebbe essere impostata a 0022 allora non verranno creati file con 777 ma al più con 0755. Ovviamente se però si imposta l'umask a 0077 allora tutto può succedere.

Non so se sai come funziona l'umask, ma ogni volta che, usando un programma cerchi di salvare un file, il programma potrebbe impostare dei suo permessi, supponi ad esempio che il gcc voglia rendere eseguibile un programma per tutti gli utenti, impostando quindi i permessi come 755. Questo valore però passa prima da un altro filtro, ovvero il valore dell'umask impostata dall'utente tramite il comando: . Il valore impostato dal programma viene messo in AND con il valore di NOT umask e quindi, se umask è 0077, allora il NOT è 7700 e quindi il programma può solo abilitare i permessi all'utente proprietario. Ti posto un esempio completo, che a volte un esempio vale più di mille parole.

Crea un file, casa.c, con questo contenuto: poi imposta umask a 0022 (dovrebbe già essere così) con: e lancia ora faie ottieni ora invece imposta umask a 0077 e rilancia gcc, vedrai che i permessi di a.out non sono più -rwxr-xr-x ma sono -rwx------.

Spina

Mario Vanoni ha scritto: Scaricato dal sito officiale sqlite-3.5.7,
tar ..., poi esattamente quello che dici di aver fatto,
i permessi in /tmp/package-sqlite/usr/lib sono
esattamente come sopra, 0755 o 0644 per *.a.

L'unico che puo` risolvere il tuo problema sei _tu_!

Mario Vanoni

PS Ovviamente come utente root!

Mi riferivo ai symlink, che poi vengono rigenerati nel doinst.sh e vengono gestiti da makepkg. Comunque grazie per la prova.

@spina: Si...infatti era un non problema. Ho postato senza connettere il cervello (è almeno la seconda volta nel giro di due settimane... ).
Umask lo conoscevo...e lo dimenticavo. Comunque grazie per il ripasso...torna sempre utile.