Newsgroup: it.comp.macintosh
Titolo: Permissioni di un processo

Ciao a tutti 
Mi servirebbe sapere se è corretto dire che un 
processo ha permissioni identiche a quelle del 
possessore del relativo file eseguibile. 
Inoltre ho notato che sulla mia macchina i programmi 
sembrano appartenere all'account amministratore con 
il quale li ho installati: vorrei capire se su un 
server si deve invece creare uno specifico utente per 
ogni deamon e impostare le sue permissioni in modo 
che gli sia consentito fare solo ciò che deve poter 
fare quel deamon. 
In queste situazioni la mia sensazione è che a un 
tale utente dovrebbero essere vietate tutte le 
attività tipo il login e le dotazioni tipo la home: 
se le cose stanno così, è corretto dire che questo 
tipo di account va preparato da linea di comando 
perché le preferenze di sistema non supportano 
queste situazioni? 
Abbiate pazienza per le fregnacce che devo aver 
scritto: sto cercando di capire da solo il più 
possibile di sta cosa e sembra proprio che sia 
arrivato alla frutta.  x:) 
Grazie infinite. 
giordano 

possessore del relativo file eseguibile. 
Ciò accade solo quando l'eseguibile ha il flag SUID
(Set User ID) attivo. Molti comandi di sistema possono
assumere in Mac OS X l'onnipotenza di root, anche se il
relativo account è disattivato, proprio perché hanno
lo UserID posto a 0 (quello di root) e il flag SUID
attivato.
-- Guido

 Quindi no, non e' corretto.
E immagini male. Frugandoti in tasca trovi anche 
qualcosa di utile o questo è tutto quello che hai?  
giordano 

 
la mia esperienza e' piu' su linux e simili ma non penso ci siano 
grossse differenze con macosx su questi argomenti.
ah guarda che si dice permessi!!

 (Set User ID) attivo. 
Grazie mille, a questo non sarei mai arrivato.  :) 
Il suggerimento č stato preziosissimo: ho mollato 
i cinque libri su OSX che nulla sembrano dire al 
riguardo e ho trovato la spiega e le istruzioni in 
uno che parla di Unix. Mi resta perň il dubbio di 
capire come devo procedere per portare a termine il 
compito che mi č stato assegnato, ovvero impostare 
una installazione di Distiller Server. 
Ho trovato molte spiegazioni sulle impostazioni degli 
utenti umani, ie con diritto di login, e sui vari 
server, ma non ho chiare le idee su come si gestiscono 
i batch che non necessitano di accessi particolari e 
si limitano ad elaborare il contenuto di una parte del 
filesystem consumando e generando file in quel contesto. 
La mia idea di un account ad hoc (niente shell ecc) 
va bene o c'č un altro metodo per trattare queste 
situazioni? 
Grazie ancora. 
giordano 

 ah guarda che si dice permessi!!
Diciamo che è più gettonato. 
Comunque sia, a furor di popolo mi converto a 'permessi' 
qui su icm. 
Grazie mille: questo genere di aiuti fa fare più passi 
avanti di tante pagine scritte.  :) 
giordano 

 qui su icm. 
Caspita, non si finisce veramente mai di imparare - linguistica su ICM!
La bagarre scatenata mi ha incuriosito ed effettivamente il De Mauro
riporta "permissione" nell'accezione di "permesso, autorizzazione",
tuttavia classificandolo come vocabolo di basso uso (appunto, meno
gettonato:)  

 gettonato:)
Sai cos'è? Che sono troppo vecchio. 
In questa accezione, 'permissione' temo sia solo 
una vetusta e brutta derivazione dall'inglese, una 
di quelle nefandezze che ci permettevamo quando il 
nostro rapporto di dipendenza coloniale aveva meno 
bisogno di essere camuffato: ad allora risale per 
l'appunto il mio primo incontro con Unix.  :) 
giordano barbogio 

 
In questa pagina più o meno è descritta la questione nel mondo POSIX:
http://www.si.hhs.nl/~bertn/gnu_libc/libc_429.html#SEC429

 
http://www.si.hhs.nl/~bertn/gnu_libc/libc_429.html#SEC429
Grazie infinite, altra cosa alla quale non penso 
sarei mai arrivato.  :) 
Questo ng conferma di ospitare democraticamente 
i due estremi del mondo usenet. E a proposito: 
un ciao anche ai soliti bisticcioni; siete 
sempre nel mio cuore.  :))) 
giordano etciù 

 qualcosa di utile o questo è tutto quello che hai?  
in tasca ho un bel killfile :)
scherzi a parte, motiva.
in generale un processo ha i permessi dell'utente che lo ha lanciato,
non del proprietario.
se no pensa per esempio a questa riga quanto sarebbe dannosa
-rwxr-xr-x  1 root  wheel     603488 27 May 09:18 bash
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan

 non del proprietario.
Infatti. E adesso l'ho capito anch'io. 
Mi sembra anche di aver trovato conferma 
del fatto che il caso di mio interesse 
fa eccezione, in quanto ha il flag SetUID 
attivato per utilizzare un'utenza come 
nobody. 
giordano 

 nobody
parecchio insolita come politica di sicurezza...
ma non ho capito... che processo e`?


 ma non ho capito... che processo e`?
Mi sa che non ho capito una cippa io.  x:))) 
Il caso di mio interesse è quello di un processo che 
gira elaborando il filesystem locale come attività 
batch. 
Attualmente devo impostare un Distiller Server che, se 
qualcosa ho capito, con SetUID disattivato dipenderebbe 
dai permessi del login di avvio, altrimenti da quelli 
di chi lo possiede. Il secondo caso mi sembra rischioso 
se non cambio il valore attuale che è quello di un 
utente con diritti admin. Il primo mi pare soggetto 
a variabili come l'iniziativa di un utente di riavviare 
la macchina con un account di sua scelta (l'ambiente in 
questione è poco controllabile). Così, da perfetto 
niubbo, mi chiedevo se non fosse il caso di sfruttare 
i vantaggi di invariabilità offerti dal SetUID abbinando 
loro le limitazioni di accesso tipiche di un account 
come nobody. Sull'opportunità di utilizzare utenze ad 
hoc ho trovato cenni qua e là, ma mi pare di capire 
che la mia è tutta una sega mentale.  x:) 
Btw, quello citato è solo un esempio: sto leggendomi 
tutta la parte di GNU C Library che mi è stata indicata 
e mi piacerebbe capire come devono essere impostate le 
cose in generale per questo tipo di processi. Non ho  
nessuna opinione personale, cerco solo di appurare 
come devo procedere. 
Se c'hai voglia, dimmi come lo imposteresti tu; così 
facciamo prima ed evito di proferire altre nefandezze.  :) 
giordano 

 facciamo prima ed evito di proferire altre nefandezze.  :) 
io non ho capito esattamente che processo e`. Nel senso... se e` un
'processo server' puoi farlo controllare da inetd oppure anche con
cron...
cioe` io non ho capito di cosa stai parlando. Un Distiller Server? Sara`
mica quello di Adobe? In caso contrario:
E poi e` un'applicazione di stampo unix, o una applicazione 'MacOS
style'?
Poi bisogna vedere un poco come e` scritta l'applicazione... ovvero
'come utilizza' il setuid... che di per se vuole dire che ha il permesso
di prendersi i diritti di root... non che  giri *sempre* con i diritti
di root, afair.
Chi fornisce l'applicazione cosa consiglia? Nel caso sia nobody + suid
avranno le loro ragioni e la avranno scritta per funzionare cosi`.
Oppure se non ha effettivamente bisogno dei permessi di root ed e` un
server 'unix style' (terminologia impropria... per capirsi, una roba
tipo apache o ftpd), puoi farla girare con l'utente ad hoc...


 io non ho capito esattamente che processo e`. 
Mi dispiace di averti fatto arrovellare. Ti ringrazio 
per la grande pazienza.  :) 
Si tratta della versione server di Distiller della Adobe, 
che è un'applicazione OSX ma in questo caso deve funzionare 
aderendo a questo limitatissimo schema: 
- ogni utente pippo ha una cartella 'pippo' 
- nella cartella 'pippo' ci sono le cartelle 'in' e 'out' 
- 'in' serve all'utente per depositare un file PostScript 
  che Distiller deve leggere e poi cancellare 
- 'out' serve a Distiller per depositare il pdf e/o il log 
  risultanti e all'utente per recuperarli. 
Il processo è dunque un server, ma la sua esigenza di 
interazione con il sistema è limitata a una piccola 
porzione locale del filesystem. Niente porte e niente 
accessi privilegiati. Mi sono quindi chiesto se le sue 
permissioni dovessero essere tanto ampie quanto quelle 
del login che la lancia (e che nulla ha a che vedere con 
l'utenza del processo) o, peggio ancora, quanto quelle 
di chi l'ha installato. 
Procedendo nello studio della GNU C Library mi sono reso 
conto, per l'appunto, di quello che dici tu: l'applicazione 
ha un certo margine di arbitrio nello swappare le sue due 
personalità real e effective (non credo invece - ma ora 
indagherò in merito - che nel mio caso l'applicativo giri 
come root). 
Mi dispiace di avere interpellato il ng su una questione 
che a questo punto mi sembra di capire sia sostanzialmente 
incentrata sulle caratteristiche del singolo applicativo. 
Se mi riesce di arrivare a qualcosa, mi farò vivo con le 
conclusioni. 
Grazie ancora di tutto.  :) 
giordano