Newsgroup: it.comp.os.linux.iniziare
Titolo: set-user-ID e set-group-ID

Per quanto ne so, se un file eseguibile ha impostati i bit riguardanti
il set-user-ID e set-group-ID nel suo mode, allora il processo associato
a tale file, "viaggia" con un effective-group ID e un effective-user ID
pari rispettivamente all'user-ID del file e al group ID del file. 
Fin qui OK per quanto riguarda un file eseguibile. Ma se imposto i bit 
i bit riguardanti il set-user-ID e set-group-ID nel campo mode di un
file-normale (ad esempio un file di testo), quale è il significato di
tale azione?
Un'altra cosa, se io imposto un file normale eseguibile, che
significato ha?
Sono nuovo del mondo GNU/linux e dei sistemi UNIX-Like, se c'è qualche
esperto che ha le risposte alle mie domande può farsi avanti lo
ringrazio anticipatamente.
-- 
arius81
------------------------------------------------------------------------
arius81's Profile: 
http://www.linuxforum.it/member.php?userid=680
View this thread: 
http://www.linuxforum.it/showthread.php?t=15519

 
Penso che la prenda dal lato sbagliato.
La domanda che dovrebbe farsi e' "Come si comportera' il programma che legge
tali files?"
Modificare un permesso non cambia la natura di un file: sono solo delle
informazioni in piu' che un programma puo' leggere o no quando apre un
file.
Non e' proprio cosi', ma abbastanza.


Mi spiego meglio forse con un esempio: il programma associato al
comando  passwd(1), dato che ha il bit set-user-ID attivo , e dato che
il suo proprietario è root, un utente qualsiasi(intendo dire un utente
che non ha privilegi da superuser) usandolo può può modificare il
famigerato file di password (il quale può essere modificato solo dal
superuser), per i suoi scopi. ....Ok...
Un altro esempio: se una directory ha i suo bel bit di set-group-ID
attivo, e ci si crea un bel file al suo interno, allora tale file avrà
il suo group-ID pari al group-ID della cartella.
Bene come puoi vedere l'impostazione di settare il set-group-ID ad un
file eseguibile e impostare il set-group-ID ad una directory ha
significati ed effetti completamente diversi.
Per questo non capisco la tua affermazione:"La domanda che dovrebbe
farsi e' "Come si comportera' il programma che legge tali files?".
Bene.
Ora il mio scopo era quello di capire, il significato dell' attivare il
set-user-ID O il set-group-ID ad un file NORMALE. (dove io per file
normale intendo un file la cui interpretazione o semantica è lasciata al
programma specifico che lo legge, come ad esempio un file txt).


 il set-user-ID e set-group-ID nel suo mode, allora il processo associato
]zac[
Per un file non eseguibile i bit set non dovrebbero essere gestiti se non i
casi particolarissimi (simulazione del lock globale di accesso al file).
Per la directory invece dovrebbe attivare la creazione dei file nella
directory con lo stesso proprietario della directory stessa.

 
Tutti i files sono "normali".
La shell permette di eseguire i file +x perche' leggendoli vede che sono +x,
ma e' una sua (non molto) "libera" interpretazione.
Un file immagine puo' essere 777, ma all'editor che si usa per aprirlo poco
importa se sia eseguibile o meno: si potrebbe implementare una funzione che
imposti 766 se il file e' stato creato al mattino, 676 se il file e' stato
creato al pomeriggio, 667 se il file e' stato creato la sera e poi farle
notificare "il file e' stato creato la mattina/il pomeriggio/la sera".
Basti pensare ad esempio allo sticky bit che ha ricoperto vari usi:
semplicemente non sapendo dove mettere un bit di informazione, lo mettevano
li'.
Ho dato per scontato che lei conoscesse i permessi ottali,
1 = esecuzione
2 = scrittura
4 = lettura
il primo numero rappresenta il proprietario, il secondo il gruppo, il terzo
gli altri.

Ringrazio innanzitutto per l'attenzione prestatami. 
Quoto"marsupiale pelato"
Non sono d'accordo con lei. In un sistema UNIX-like i file non sono
tutti file normali: esistono file directory, file a blocchi, file
speciali, file eseguibili, ecc ecc. é ovvio che la distinzione che a
essi si fa non è tanto sul loro contenuto, ma è data dalla loro
interpretazione e da cosa si può fare con essi.
Poi è ovvio che impostando un file normale con +x, lo si rende
eseguibile, ma se tale file è normale (ovvero non ha la struttura
semantica di un file eseguibile) allora quando , il kernel lo tentera di
eseguire sarà un completo fallimento.
Quindi mi dissocio con lei completamente.
Comunque la questione del post era completamente diversa da questa.
Tra l'altro io sto parlando di bit di set(che grossolanamete possiamo
anche associarli ai bit di permesso)  colgo l'occasione per quotare
"Giuseppe Della bianca", magari si è vero che non dovrebbero essere
gestiti, ma molte cose che non doverebbero essere gestite sono gestite
per aggirare alcune protezioni e sistemi informatici. A me piace
studiare i casi estremi. 
Pensavo di trovare qualche smanettone in questo forum: eek:.


 Pensavo di trovare qualche smanettone in questo forum: eek:.
Beh guarda io pensavo di rispondere un essere senziente e non a un adepto
della pappa pronta e delle domande senza senso/limite.
Chi può garantire che un programma non faccia quello che non dovrebbe
assolutamente fare? chi può garantire che un bug faccia anche di peggio?
E mi sembrerebbe molto strano che qualcuno che conosca degli 'hack' costati
magari molta fatica li regali al primo ''sbarbatello'' pensante.

quoto "Giuseppe Della Bianca"
Perchč dovrei essere uno sbarbatello pensante?che ne sai tu di me?
In ogni caso, non mi sono offeso, e non penso che questo era il tuo
intento, sono stato sempre un tipo molto amichevole e che pensa che
l'informazione debba essere la prima di ogni altra cosa che debba essere
condivisa( mi riferisco alla tua ultima proposizione).
Cmq la domanda che avevo originariamente postata, non l'ho trovata in
nessuno dei messaggi mandati in questo post(e non pretendo che ci sia).
