piccole convenzioni.
rispettivamente uno \textit{shared lock}, un \textit{esclusive lock}, e la
rimozione di un blocco precedentemente acquisito. Infine il campo \var{l\_pid}
viene usato solo in caso di lettura, quando si chiama \func{fcntl} con
-\const{F\_GETLK}, e riporta il \acr{pid} del processo che detiene il
+\const{F\_GETLK}, e riporta il \ids{PID} del processo che detiene il
\textit{file lock}.
Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
sono evidenziati solo i campi di \struct{file\_lock} significativi per la
semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
- \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
+ \ids{PID} del processo in \var{fl\_pid}, la sezione di file che viene
bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
usato.} il blocco è sempre associato \itindex{inode} all'inode, solo che in
questo caso la titolarità non viene identificata con il riferimento ad una
voce nella \itindex{file~table} \textit{file table}, ma con il valore del
-\acr{pid} del processo.
+\ids{PID} del processo.
\begin{figure}[!htb]
\centering \includegraphics[width=12cm]{img/file_posix_lock}
caso negativo il nuovo blocco viene comunque acquisito ed aggiunto alla lista.
Nel caso di rimozione invece questa viene effettuata controllando che il
-\acr{pid} del processo richiedente corrisponda a quello contenuto nel blocco.
+\ids{PID} del processo richiedente corrisponda a quello contenuto nel blocco.
Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
dei \textit{file lock} POSIX. La prima conseguenza è che un \textit{file lock}
POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo
-figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
-\func{exec} in quanto il \acr{pid} resta lo stesso. Questo comporta che, al
+figlio avrà un \ids{PID} diverso, mentre passa indenne attraverso una
+\func{exec} in quanto il \ids{PID} resta lo stesso. Questo comporta che, al
contrario di quanto avveniva con la semantica BSD, quando un processo termina
tutti i \textit{file lock} da esso detenuti vengono immediatamente rilasciati.
La seconda conseguenza è che qualunque file descriptor che faccia riferimento
allo stesso file (che sia stato ottenuto con una \func{dup} o con una
\func{open} in questo caso non fa differenza) può essere usato per rimuovere
-un blocco, dato che quello che conta è solo il \acr{pid} del processo. Da
+un blocco, dato che quello che conta è solo il \ids{PID} del processo. Da
questo deriva una ulteriore sottile differenza di comportamento: dato che alla
chiusura di un file i blocchi ad esso associati vengono rimossi, nella
semantica POSIX basterà chiudere un file descriptor qualunque per cancellare
fossero stati creati usando altri file descriptor che restano aperti.
Dato che il controllo sull'accesso ai blocchi viene eseguito sulla base del
-\acr{pid} del processo, possiamo anche prendere in considerazione un altro
+\ids{PID} del processo, possiamo anche prendere in considerazione un altro
degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
richiedono dei blocchi su regioni che si sovrappongono fra loro all'interno
stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
-solo sul \acr{pid} del processo che chiama la funzione, queste richieste
+solo sul \ids{PID} del processo che chiama la funzione, queste richieste
avranno sempre successo.
Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda
quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
-utilizzato per cambiare il \acr{gid} effettivo con cui viene eseguito un
+utilizzato per cambiare il \ids{GID} effettivo con cui viene eseguito un
programma, ed è pertanto sempre associato alla presenza del permesso di
esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
su un file, e che un \textit{lease} può essere ottenuto solo su file di dati
(pipe e dispositivi sono quindi esclusi). Inoltre un processo non privilegiato
può ottenere un \textit{lease} soltanto per un file appartenente ad un
-\acr{uid} corrispondente a quello del processo. Soltanto un processo con
+\ids{UID} corrispondente a quello del processo. Soltanto un processo con
privilegi di amministratore (cioè con la \itindex{capabilities} capability
\const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
\textit{lease} su qualunque file.
gruppo primario del processo, eccetto il caso in cui la directory ha il bit
di \acr{sgid} impostato (per una descrizione dettagliata del significato di
questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
- file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
+ file e subdirectory ereditano sia il \ids{GID} che lo \acr{sgid}.
\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
in fase di creazione, a seconda delle sue esigenze: blocchi più grandi
permettono un accesso più veloce, ma sprecano più spazio disco.
\begin{errlist}
\item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
directory, oppure la directory che contiene \param{dirname} ha lo
- \itindex{sticky~bit} \textit{sticky bit} impostato e l'\acr{uid} effettivo
+ \itindex{sticky~bit} \textit{sticky bit} impostato e l'\ids{UID} effettivo
del processo non corrisponde al proprietario della directory.
\item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory
che contiene la directory che si vuole cancellare, o non c'è il permesso
funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
alle possibili \itindex{race~condition} \textit{race condition} date per
\func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
-il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid}
+il valore usato per sostituire le \code{XXXXXX} viene formato con il \ids{PID}
del processo più una lettera, il che mette a disposizione solo 26 possibilità
diverse per il nome del file, e rende il nome temporaneo facile da indovinare.
Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
-degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori
+degli identificatori di utente e gruppo (\ids{UID} e \ids{GID}). Questi valori
sono accessibili da programma tramite la funzione \func{stat}, e sono
mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura
\struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo
La procedura con cui il kernel stabilisce se un processo possiede un certo
permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
-\var{st\_gid} accennati in precedenza) e l'\acr{uid} effettivo, il \acr{gid}
-effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in
+\var{st\_gid} accennati in precedenza) e l'\ids{UID} effettivo, il \ids{GID}
+effettivo e gli eventuali \ids{GID} supplementari del processo.\footnote{in
realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli
identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
Per una spiegazione dettagliata degli identificatori associati ai processi si
veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in
-sez.~\ref{sec:file_special_perm}, l'\acr{uid} effettivo e il \acr{gid} effettivo
-corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
-lanciato il processo, mentre i \acr{gid} supplementari sono quelli dei gruppi
+sez.~\ref{sec:file_special_perm}, l'\ids{UID} effettivo e il \ids{GID} effettivo
+corrispondono ai valori dell'\ids{UID} e del \ids{GID} dell'utente che ha
+lanciato il processo, mentre i \ids{GID} supplementari sono quelli dei gruppi
cui l'utente appartiene.
I passi attraverso i quali viene stabilito se il processo possiede il diritto
di accesso sono i seguenti:
\begin{enumerate}
-\item Se l'\acr{uid} effettivo del processo è zero (corrispondente
+\item Se l'\ids{UID} effettivo del processo è zero (corrispondente
all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
tutti i file.
-\item Se l'\acr{uid} effettivo del processo è uguale all'\acr{uid} del
+\item Se l'\ids{UID} effettivo del processo è uguale all'\ids{UID} del
proprietario del file (nel qual caso si dice che il processo è proprietario
del file) allora:
\begin{itemize*}
impostato, l'accesso è consentito
\item altrimenti l'accesso è negato
\end{itemize*}
-\item Se il \acr{gid} effettivo del processo o uno dei \acr{gid} supplementari
- dei processi corrispondono al \acr{gid} del file allora:
+\item Se il \ids{GID} effettivo del processo o uno dei \ids{GID} supplementari
+ dei processi corrispondono al \ids{GID} del file allora:
\begin{itemize*}
\item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
consentito,
Se però il file del programma (che ovviamente deve essere
eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid}
e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il
-kernel assegnerà come \acr{uid} effettivo al nuovo processo l'\acr{uid} del
-proprietario del file al posto dell'\acr{uid} del processo originario. Avere
-il bit \acr{sgid} impostato ha lo stesso effetto sul \acr{gid} effettivo del
+kernel assegnerà come \ids{UID} effettivo al nuovo processo l'\ids{UID} del
+proprietario del file al posto dell'\ids{UID} del processo originario. Avere
+il bit \acr{sgid} impostato ha lo stesso effetto sul \ids{GID} effettivo del
processo.
I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
\label{sec:file_perm_management}
Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
-file viene fatto utilizzando l'\acr{uid} ed il \acr{gid} effettivo del processo;
-ci sono casi però in cui si può voler effettuare il controllo con l'\acr{uid}
-reale ed il \acr{gid} reale, vale a dire usando i valori di \acr{uid} e
-\acr{gid} relativi all'utente che ha lanciato il programma, e che, come
+file viene fatto utilizzando l'\ids{UID} ed il \ids{GID} effettivo del processo;
+ci sono casi però in cui si può voler effettuare il controllo con l'\ids{UID}
+reale ed il \ids{GID} reale, vale a dire usando i valori di \ids{UID} e
+\ids{GID} relativi all'utente che ha lanciato il programma, e che, come
accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
\bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
proprietario del file o non è zero.
\item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
\end{errlist}
Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
-funzioni infatti è possibile solo se l'\acr{uid} effettivo del processo
+funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo
corrisponde a quello del proprietario del file o dell'amministratore,
altrimenti esse falliranno con un errore di \errcode{EPERM}.
in particolare accade che:
\begin{enumerate}
\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
- \textit{sticky bit}, se l'\acr{uid} effettivo del processo non è zero esso
+ \textit{sticky bit}, se l'\ids{UID} effettivo del processo non è zero esso
viene automaticamente cancellato (senza notifica di errore) qualora sia
stato indicato in \param{mode}.
\item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
un file appartenente ad un gruppo per cui non si hanno diritti, questo viene
automaticamente cancellato da \param{mode} (senza notifica di errore)
qualora il gruppo del file non corrisponda a quelli associati al processo
- (la cosa non avviene quando l'\acr{uid} effettivo del processo è zero).
+ (la cosa non avviene quando l'\ids{UID} effettivo del processo è zero).
\end{enumerate}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
per la creazione di nuove directory (procedimento descritto in
sez.~\ref{sec:file_dir_creat_rem}).
-Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
-all'\acr{uid} effettivo del processo che lo crea; per il \acr{gid} invece prevede
-due diverse possibilità:
+Lo standard POSIX prescrive che l'\ids{UID} del nuovo file corrisponda
+all'\ids{UID} effettivo del processo che lo crea; per il \ids{GID} invece
+prevede due diverse possibilità:
\begin{itemize*}
-\item il \acr{gid} del file corrisponde al \acr{gid} effettivo del processo.
-\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
+\item il \ids{GID} del file corrisponde al \ids{GID} effettivo del processo.
+\item il \ids{GID} del file corrisponde al \ids{GID} della directory in cui
esso è creato.
\end{itemize*}
in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
-\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+\ids{GID} del processo, se però la directory in cui viene creato il file ha il
bit \acr{sgid} impostato allora viene usata la seconda opzione.
-Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+Usare la semantica BSD ha il vantaggio che il \ids{GID} viene sempre
automaticamente propagato, restando coerente a quello della directory di
partenza, in tutte le sotto-directory.
directory venga anche propagato anche il bit \acr{sgid}. Questo è il
comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad
esempio che le varie distribuzioni assicurano che le sotto-directory create
-nella home di un utente restino sempre con il \acr{gid} del gruppo primario
+nella home di un utente restino sempre con il \ids{GID} del gruppo primario
dello stesso.
La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
errore, nel qual caso caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
proprietario del file o non è zero, o utente e gruppo non sono validi
\end{errlist}
Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e
ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
sono i seguenti:
\begin{enumerate*}
-\item Se l'\acr{uid} del processo è nullo l'accesso è sempre garantito senza
+\item Se l'\ids{UID} del processo è nullo l'accesso è sempre garantito senza
nessun controllo.
-\item Se l'\acr{uid} del processo corrisponde al proprietario del file allora:
+\item Se l'\ids{UID} del processo corrisponde al proprietario del file allora:
\begin{itemize*}
\item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
l'accesso è consentito;
\item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se l'\acr{uid} del processo corrisponde ad un qualunque qualificatore
+\item Se l'\ids{UID} del processo corrisponde ad un qualunque qualificatore
presente in una voce \const{ACL\_USER} allora:
\begin{itemize*}
\item se la voce \const{ACL\_USER} corrispondente e la voce
consentito;
\item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari
+\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari
corrisponde al gruppo proprietario del file allora:
\begin{itemize*}
\item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
l'accesso è consentito;
\item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari
+\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari
corrisponde ad un qualunque qualificatore presente in una voce
\const{ACL\_GROUP} allora:
\begin{itemize*}
\hline
\const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\
\const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
- \acr{uid} e \acr{gid}.\\
+ \ids{UID} e \ids{GID}.\\
\const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
vengono eliminati dalla \const{ACL\_MASK}
viene generato un commento con i permessi
con il supporto delle quote abilitato; esso deve essere specificato con il
nome del file di dispositivo nell'argomento \param{dev}. Per le operazioni che
lo richiedono inoltre si dovrà indicare con l'argomento \param{id} l'utente o
-il gruppo (specificati rispettivamente per \acr{uid} e \acr{gid}) su cui si
+il gruppo (specificati rispettivamente per \ids{UID} e \ids{GID}) su cui si
vuole operare. Alcune operazioni usano l'argomento \param{addr} per indicare
un indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione
stessa.
\hline
\const{QFMT\_VFS\_OLD}& il vecchio (ed obsoleto) formato delle quote.\\
\const{QFMT\_VFS\_V0} & la versione 0 usata dal VFS di Linux (supporta
- \acr{uid} e \acr{gid} a 32 bit e limiti fino a
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
$2^{42}$ byte e $2^{32}$ file.\\
\const{QFMT\_VFS\_V1} & la versione 1 usata dal VFS di Linux (supporta
- \acr{uid} e \acr{GID} a 32 bit e limiti fino a
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
$2^{64}$ byte e $2^{64}$ file.\\
\hline
\end{tabular}
privilegi originali dal processo.
Per questo motivo se un programma senza \textit{capabilities} assegnate viene
-eseguito da un processo con \acr{uid} reale 0, esso verrà trattato come
+eseguito da un processo con \ids{UID} reale 0, esso verrà trattato come
se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con
tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo,
col risultato di fornire comunque al processo tutte le capacità presenti nel
riesce così a riottenere il comportamento classico di un sistema unix-like.
Una seconda circostanza è quella relativa a cosa succede alle
-\textit{capabilities} di un processo nelle possibili transizioni da \acr{uid}
-nullo a \acr{uid} non nullo o viceversa (corrispondenti rispettivamente a
+\textit{capabilities} di un processo nelle possibili transizioni da \ids{UID}
+nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a
cedere o riottenere i i privilegi di amministratore) che si possono effettuare
con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la
casistica è di nuovo alquanto complessa, considerata anche la presenza dei
diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si
avrà allora che:
\begin{enumerate*}
-\item se si passa da \acr{uid} effettivo nullo a non nullo
+\item se si passa da \ids{UID} effettivo nullo a non nullo
l'\textit{effective set} del processo viene totalmente azzerato, se
- viceversa si passa da \acr{uid} effettivo non nullo a nullo il
+ viceversa si passa da \ids{UID} effettivo non nullo a nullo il
\textit{permitted set} viene copiato nell'\textit{effective set};
-\item se si passa da \textit{file system} \acr{uid} nullo a non nullo verranno
+\item se si passa da \textit{file system} \ids{UID} nullo a non nullo verranno
cancellate dall'\textit{effective set} del processo tutte le capacità
attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD},
\const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH},
ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono
mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui
valore consente di modificare queste regole speciali che si applicano ai
-processi con \acr{uid} nullo. La maschera viene sempre mantenuta
+processi con \ids{UID} nullo. La maschera viene sempre mantenuta
attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre
cancellato il flag \const{SECURE\_KEEP\_CAPS}.
\hline
\const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle
sue \textit{capabilities} quando tutti i suoi
- \acr{uid} passano ad un valore non
+ \ids{UID} passano ad un valore non
nullo (regola di compatibilità per il cambio
- di \acr{uid} n.~3 del precedente
+ di \ids{UID} n.~3 del precedente
elenco), sostituisce il precedente uso
dell'operazione \const{PR\_SET\_KEEPCAPS} di
\func{prctl}.\\
\const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
delle sue \textit{capabilities} nel passaggio
- da nullo a non nullo degli \acr{uid}
+ da nullo a non nullo degli \ids{UID}
dei gruppi \textit{effective} e
\textit{file system} (regole di compatibilità
- per il cambio di \acr{uid} nn.~1 e 2 del
+ per il cambio di \ids{UID} nn.~1 e 2 del
precedente elenco).\\
\const{SECURE\_NOROOT} & Il processo non assume nessuna capacità
aggiuntiva quando esegue un programma, anche
- se ha \acr{uid} nullo o il programma ha
+ se ha \ids{UID} nullo o il programma ha
il \acr{suid} bit attivo ed appartiene
all'amministratore (regola di compatibilità
per l'esecuzione di programmi senza
La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
processo che non ha la proprietà di un file in un vasto campo di
-operazioni;\footnote{vale a dire la richiesta che l'\acr{uid} effettivo del
- processo (o meglio l'\acr{uid} di filesystem, vedi
+operazioni;\footnote{vale a dire la richiesta che l'\ids{UID} effettivo del
+ processo (o meglio l'\ids{UID} di filesystem, vedi
sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste
comprendono i cambiamenti dei permessi e dei tempi del file (vedi
sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su
qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
-(vedi sez.~\ref{sec:file_xattr}), specificare un \acr{uid} arbitrario
+(vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario
nella trasmissione delle credenziali dei socket (vedi
sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate
(\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
\bodydesc{La funzione restituisce zero in caso di successo e -1 per
un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'\acr{uid} effettivo del processo non è zero.
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo del processo non è zero.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
esso può essere specificato come maschera binaria di due valori:
\begin{basedescript}{\desclabelwidth{3.0cm}}
\item[\const{AT\_EACCESS}] se impostato \funcd{faccessat} esegue il controllo
- dei permessi usando l'\acr{uid} effettivo invece di quello reale (il
+ dei permessi usando l'\ids{UID} effettivo invece di quello reale (il
comportamento di default, che riprende quello di \func{access}).
\item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato \funcd{faccessat} non esegue
la dereferenziazione dei link simbolici, effettuando il controllo dei
imposta \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore
nullo. Questa funzionalità è trattata in dettaglio in
sez.~\ref{sec:file_posix_lock}.
-\item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o
+\item[\const{F\_GETOWN}] restituisce il \ids{PID} del processo o
l'identificatore del \itindex{process~group} \textit{process
group}\footnote{i \itindex{process~group} \textit{process group} sono
(vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel
controllo di sessione; a ciascuno di essi è associato un identificatore
- (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione
+ (un numero positivo analogo al \ids{PID}).} che è preposto alla ricezione
dei segnali \signal{SIGIO}\footnote{o qualunque altro segnale alternativo
impostato con \const{F\_FSETSIG}.} per gli eventi associati al file
descriptor \param{fd}\footnote{il segnale viene usato sia per il
\itindex{Name~Service~Switch} \textit{Name Service Switch}, su varie
tipologie di supporti, compresi server centralizzati come LDAP.} Questi
identificativi sono l'\textit{user identifier}, detto in breve
-\textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il \textit{group
+\textsl{user-ID}, ed indicato dall'acronimo \ids{UID}, e il \textit{group
identifier}, detto in breve \textsl{group-ID}, ed identificato dall'acronimo
-\acr{gid}, torneremo in dettaglio su questo argomento in
+\ids{GID}, torneremo in dettaglio su questo argomento in
sez.~\ref{sec:proc_perms}. Il kernel conosce ed utilizza soltanto questi
valori numerici, i nomi ad essi associati sono interamente gestiti in
\textit{user space} con opportune funzioni di libreria, torneremo su questo
Infine in ogni sistema unix-like è presente uno speciale utente privilegiato,
il cosiddetto \textit{superuser}, il cui username è di norma \textit{root}, ed
-il cui \acr{uid} è zero. Esso identifica l'amministratore del sistema, che
+il cui \ids{UID} è zero. Esso identifica l'amministratore del sistema, che
deve essere in grado di fare qualunque operazione; per l'utente \textit{root}
infatti i meccanismi di controllo cui si è accennato in precedenza sono
disattivati.\footnote{i controlli infatti vengono eseguiti da uno pseudo-codice
\end{figure}
La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
-essere utilizzata per ricevere la risposta dal server. Si usa il \acr{pid}
+essere utilizzata per ricevere la risposta dal server. Si usa il \ids{PID}
del processo per essere sicuri di avere un nome univoco; dopo di che
(\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
in caso di errore (a meno che il file non sia già presente sul filesystem).
Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
IPC} vengono creati direttamente dal kernel, e sono accessibili solo
specificando il relativo \textsl{identificatore}. Questo è un numero
-progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a
+progressivo (un po' come il \ids{PID} dei processi) che il kernel assegna a
ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
\struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati
-rispettivamente al valore dell'\acr{uid} e del \acr{gid} effettivo del processo
+rispettivamente al valore dell'\ids{UID} e del \ids{GID} effettivo del processo
che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
\begin{itemize*}
\item se il processo ha i privilegi di amministratore l'accesso è sempre
consentito.
-\item se l'\acr{uid} effettivo del processo corrisponde o al valore del campo
+\item se l'\ids{UID} effettivo del processo corrisponde o al valore del campo
\var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
in \var{mode} è appropriato\footnote{per appropriato si intende che è
impostato il permesso di scrittura per le operazioni di scrittura e quello
di lettura per le operazioni di lettura.} l'accesso è consentito.
-\item se il \acr{gid} effettivo del processo corrisponde o al
+\item se il \ids{GID} effettivo del processo corrisponde o al
valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
per il gruppo in \var{mode} è appropriato l'accesso è consentito.
\item se il permesso per gli altri è appropriato l'accesso è consentito.
\item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti
sulla coda, viene inizializzato a 0.
\item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono
- rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto
+ rispettivamente il \ids{PID} dell'ultimo processo che ha inviato o ricevuto
un messaggio sulla coda, sono inizializzati a 0.
\item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo
il medesimo errore. Questo comando può essere eseguito solo da un processo
- con \acr{uid} effettivo corrispondente al creatore o al proprietario della
+ con \ids{UID} effettivo corrispondente al creatore o al proprietario della
coda, o all'amministratore.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
vengono modificati:
\begin{itemize*}
-\item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del
+\item Il valore di \var{msg\_lspid}, che viene impostato al \ids{PID} del
processo chiamante.
\item Il valore di \var{msg\_qnum}, che viene incrementato di uno.
\item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
vengono modificati:
\begin{itemize*}
-\item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del
+\item Il valore di \var{msg\_lrpid}, che viene impostato al \ids{PID} del
processo chiamante.
\item Il valore di \var{msg\_qnum}, che viene decrementato di uno.
\item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente.
\file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
per permettere una comunicazione indipendente fra il server ed i vari client,
-usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
+usando il \ids{PID} di questi ultimi come identificativo. Questo è possibile
in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
base del loro tipo.
34}) con il porsi in attesa di un messaggio di richiesta da parte di un
client; si noti infatti come \func{msgrcv} richieda un messaggio con
\var{mtype} uguale a 1: questo è il valore usato per le richieste dato che
-corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso
+corrisponde al \ids{PID} di \cmd{init}, che non può essere un client. L'uso
del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di
-richiesta sono di dimensione fissa (e contengono solo il \acr{pid} del
+richiesta sono di dimensione fissa (e contengono solo il \ids{PID} del
client).
Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
Per poter permettere a ciascun client di ricevere solo la risposta indirizzata
a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 38})
-al valore del \acr{pid} del client ricevuto nel messaggio di richiesta.
+al valore del \ids{PID} del client ricevuto nel messaggio di richiesta.
L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il
messaggio di risposta. Si tenga conto che se la coda è piena anche questa
funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
Una volta acquisito l'identificatore della coda il client compone il
messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1
-per il tipo ed inserendo il proprio \acr{pid} come dato da passare al server.
+per il tipo ed inserendo il proprio \ids{PID} come dato da passare al server.
Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad
immettere la richiesta sulla coda.
A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la
risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di
-tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo
+tipo corrispondente al valore del \ids{PID} inviato nella richiesta. L'ultimo
passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
messaggio ricevuto.
il problema delle fifo che restavano nel filesystem). In questo caso però il
problemi sono maggiori, sia perché è molto più facile esaurire la memoria
dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem,
-sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
+sia perché, con il riutilizzo dei \ids{PID} da parte dei processi, un client
eseguito in un momento successivo potrebbe ricevere un messaggio non
indirizzato a lui.
indicano rispettivamente:
\begin{description*}
\item[\var{semval}] il valore numerico del semaforo.
-\item[\var{sempid}] il \acr{pid} dell'ultimo processo che ha eseguito una
+\item[\var{sempid}] il \ids{PID} dell'ultimo processo che ha eseguito una
operazione sul semaforo.
\item[\var{semncnt}] il numero di processi in attesa che esso venga
incrementato.
\item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
dati, con effetto immediato. Tutti i processi che erano stato di
\textit{sleep} vengono svegliati, ritornando con un errore di
- \errcode{EIDRM}. L'\acr{uid} effettivo del processo deve corrispondere o al
+ \errcode{EIDRM}. L'\ids{UID} effettivo del processo deve corrispondere o al
creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
\param{semnum} viene ignorato.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
dell'insieme. I valori devono essere passati in una struttura
\struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
- significativi di \var{sem\_perm.mode}. L'\acr{uid} effettivo del processo deve
+ significativi di \var{sem\_perm.mode}. L'\ids{UID} effettivo del processo deve
corrispondere o al creatore o al proprietario dell'insieme, o
all'amministratore. L'argomento \param{semnum} viene ignorato.
\item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
\struct{sem}); va invocata con tre argomenti. Occorre avere il permesso di
lettura.
\item[\const{GETPID}] Restituisce come valore di ritorno della funzione il
- \acr{pid} dell'ultimo processo che ha compiuto una operazione sul semaforo
+ \ids{PID} dell'ultimo processo che ha compiuto una operazione sul semaforo
\param{semnum} dell'insieme \param{semid} (corrispondente al campo
\var{sempid} di \struct{sem}); va invocata con tre argomenti. Occorre avere
il permesso di lettura.
\end{basedescript}
In caso di successo della funzione viene aggiornato il campo \var{sempid} per
-ogni semaforo modificato al valore del \acr{pid} del processo chiamante;
+ogni semaforo modificato al valore del \ids{PID} del processo chiamante;
inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
\var{sem\_ctime}.
\item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono
rispettivamente il tempo dell'ultima volta che il segmento è stato
agganciato o sganciato da un processo, vengono inizializzati a zero.
-\item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha
+\item il campo \var{shm\_lpid}, che esprime il \ids{PID} del processo che ha
eseguito l'ultima operazione, viene inizializzato a zero.
-\item il campo \var{shm\_cpid}, che esprime il \acr{pid} del processo che ha
- creato il segmento, viene inizializzato al \acr{pid} del processo chiamante.
+\item il campo \var{shm\_cpid}, che esprime il \ids{PID} del processo che ha
+ creato il segmento, viene inizializzato al \ids{PID} del processo chiamante.
\item il campo \var{shm\_nattac}, che esprime il numero di processi agganciati
al segmento viene inizializzato a zero.
\end{itemize}
\item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
\const{IPC\_RMID} senza i permessi necessari.
\item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
- valore del \acr{gid} o dell'\acr{uid} è troppo grande per essere
+ valore del \ids{GID} o dell'\ids{UID} è troppo grande per essere
memorizzato nella struttura puntata da \param{buf}.
\item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
valido.
\item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
processo ad esso agganciato si sarà staccato. Questo comando può essere
- eseguito solo da un processo con \acr{uid} effettivo corrispondente o al
+ eseguito solo da un processo con \ids{UID} effettivo corrispondente o al
creatore del segmento, o al proprietario del segmento, o all'amministratore.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
del segmento. Per modificare i valori di \var{shm\_perm.mode},
\begin{itemize*}
\item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene
impostato al tempo corrente.
-\item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
+\item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul
segmento viene impostato a quello del processo corrente.
\item il numero \var{shm\_nattch} di processi agganciati al segmento viene
aumentato di uno.
\begin{itemize*}
\item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene
impostato al tempo corrente.
-\item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
+\item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul
segmento viene impostato a quello del processo corrente.
\item il numero \var{shm\_nattch} di processi agganciati al segmento viene
decrementato di uno.
sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del
SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo
proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata
-secondo la semantica SysV: corrispondono cioè a \acr{uid} e \acr{gid} effettivi
+secondo la semantica SysV: corrispondono cioè a \ids{UID} e \ids{GID} effettivi
del processo che esegue la creazione.
L'invio del segnale di notifica avvalora alcuni campi di informazione
restituiti al gestore attraverso la struttura \struct{siginfo\_t} (definita in
fig.~\ref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al
-valore del \acr{pid} del processo che ha emesso il segnale, \var{si\_uid}
+valore del \ids{PID} del processo che ha emesso il segnale, \var{si\_uid}
all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a
0. Questo ci dice che, se si effettua la ricezione dei messaggi usando
esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
usano la semantica standard dei file per quanto riguarda i controlli di
accesso.
-Questo significa che un nuovo semaforo viene sempre creato con l'\acr{uid} ed il
-\acr{gid} effettivo del processo chiamante, e che i permessi indicati con
+Questo significa che un nuovo semaforo viene sempre creato con l'\ids{UID} ed
+il \ids{GID} effettivo del processo chiamante, e che i permessi indicati con
\param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask}
del processo. Inoltre per poter aprire un semaforo è necessario avere su di
esso sia il permesso di lettura che quello di scrittura.
%\index{#1@{{\tt {#1}} (struttura dati)}!definizione di}\texttt{#1}%
} % struttura dati
\newcommand{\param}[1]{\texttt{#1}} % function parameter
-\newcommand{\acr}[1]{\textsl{#1}} % acrostic (for pid, suid, ecc.)
+\newcommand{\acr}[1]{\textsl{#1}} % acrostic (for glibc, ext2, ecc.)
+
+\newcommand{\ids}[1]{\textsl{#1}} % Identifier (PID, GID, UID, TID, ecc.)
+
+
+
+
\newcommand{\itindex}[1]{%
\index{#1@{\textit{#1}}}%
caratteristiche fondanti di Unix, che esamineremo in dettaglio più avanti, è
che qualunque processo può a sua volta generarne altri. Ogni processo è
identificato presso il sistema da un numero univoco, il cosiddetto
-\textit{process identifier} o, più brevemente, \acr{pid}, assegnato in forma
-progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
+\itindex{Process~ID~(PID)} \textit{Process ID} o, più brevemente, \ids{PID},
+assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid}) quando il
+processo viene creato.
Una seconda caratteristica di un sistema unix-like è che la generazione di un
processo è un'operazione separata rispetto al lancio di un programma. In
di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}),
che come abbiamo accennato in sez.~\ref{sec:intro_kern_and_sys} viene lanciato
dal kernel alla conclusione della fase di avvio. Essendo questo il primo
-processo lanciato dal sistema ha sempre il \acr{pid} uguale a 1 e non è figlio
+processo lanciato dal sistema ha sempre il \ids{PID} uguale a 1 e non è figlio
di nessun altro processo.
Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
del tutto vero, in Linux, specialmente nelle versioni più recenti del
kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
- \acr{pid} successivi ad uno, sono in realtà processi interni al kernel e che
+ \ids{PID} successivi ad uno, sono in realtà processi interni al kernel e che
non rientrano in questa classificazione.}
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
Come accennato nella sezione precedente ogni processo viene identificato dal
sistema da un numero identificativo univoco, il \textit{process ID} o
-\acr{pid}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
+\ids{PID}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
\ctyp{int}).
-Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
+Il \ids{PID} viene assegnato in forma progressiva ogni volta che un nuovo
processo viene creato,\footnote{in genere viene assegnato il numero successivo
a quello usato per l'ultimo processo creato, a meno che questo numero non
- sia già utilizzato per un altro \acr{pid}, \acr{pgid} o \acr{sid} (vedi
+ sia già utilizzato per un altro \ids{PID}, \acr{pgid} o \acr{sid} (vedi
sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
-tradizionalmente il \acr{pid} un numero positivo memorizzato in un intero a 16
+tradizionalmente il \ids{PID} un numero positivo memorizzato in un intero a 16
bit, arriva ad un massimo di 32768. Oltre questo valore l'assegnazione
riparte dal numero più basso disponibile a partire da un minimo di
300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro
\const{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
kernel, con il 2.6.x e la nuova interfaccia per i \itindex{thread}
- \textit{thread} anche il meccanismo di allocazione dei \acr{pid} è stato
+ \textit{thread} anche il meccanismo di allocazione dei \ids{PID} è stato
modificato ed il valore massimo è impostabile attraverso il file
\sysctlfile{kernel/pid\_max} e di default vale 32768.} che serve a
-riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
+riservare i \ids{PID} più bassi ai processi eseguiti direttamente dal kernel.
Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
-avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
+avvio (\cmd{init}) ha sempre il \ids{PID} uguale a uno.
-Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
-sono stati creati, questo viene chiamato in genere \acr{ppid} (da
-\textit{parent process ID}). Questi due identificativi possono essere
-ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui
-prototipi sono:
+Tutti i processi inoltre memorizzano anche il \ids{PID} del genitore da cui
+sono stati creati, questo viene chiamato in genere \ids{PPID} (da
+\itindex{Parent~Process~ID~(PPID)} \textit{Parent Process ID}). Questi due
+identificativi possono essere ottenuti usando le due funzioni \funcd{getpid} e
+\funcd{getppid}, i cui prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{unistd.h}
\fdecl{pid\_t getpid(void)}
-\fdesc{Restituisce il \acr{pid} del processo corrente..}
+\fdesc{Restituisce il \ids{PID} del processo corrente..}
\fdecl{pid\_t getppid(void)}
-\fdesc{Restituisce il \acr{pid} del padre del processo corrente.}
+\fdesc{Restituisce il \ids{PID} del padre del processo corrente.}
}
{Entrambe le funzioni non riportano condizioni di errore.}
\end{funcproto}
\noindent esempi dell'uso di queste funzioni sono riportati in
fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
-Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
+Il fatto che il \ids{PID} sia un numero univoco per il sistema lo rende un
candidato per generare ulteriori indicatori associati al processo di cui
diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
-\acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che
+\ids{PID} per generare un \itindex{pathname} \textit{pathname} univoco, che
non potrà essere replicato da un altro processo che usi la stessa
-funzione. Questo utilizzo però può risultare pericoloso, un \acr{pid} infatti
+funzione. Questo utilizzo però può risultare pericoloso, un \ids{PID} infatti
è univoco solo fintanto che un processo è attivo, una volta terminato esso
potrà essere riutilizzato da un processo completamente diverso, e di questo
bisogna essere ben consapevoli.
un processo e le varie relazioni fra processi utilizzate per definire una
sessione.
-Oltre al \acr{pid} e al \acr{ppid}, e a quelli che vedremo in
+Oltre al \ids{PID} e al \ids{PPID}, e a quelli che vedremo in
sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
processo vengono associati degli ulteriori identificatori ed in particolare
quelli che vengono usati per il controllo di accesso. Questi servono per
\fdecl{pid\_t fork(void)}
\fdesc{Crea un nuovo processo.}
}
-{La funzione ritorna il \acr{pid} del figlio al padre e $0$ al figlio in caso
+{La funzione ritorna il \ids{PID} del figlio al padre e $0$ al figlio in caso
di successo e $-1$ al padre senza creare il figlio per un errore,
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
state modificate, e solo al momento della modifica stessa.
La differenza che si ha nei due processi è che nel processo padre il valore di
-ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
+ritorno della funzione \func{fork} è il \ids{PID} del processo figlio, mentre
nel figlio è zero; in questo modo il programma può identificare se viene
eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
due volte, una nel padre e una nel figlio.
La scelta di questi valori di ritorno non è casuale, un processo infatti può
avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
permette di identificare quello appena creato. Al contrario un figlio ha
-sempre un solo padre, il cui \acr{pid} può sempre essere ottenuto con
+sempre un solo padre, il cui \ids{PID} può sempre essere ottenuto con
\func{getppid}, come spiegato in sez.~\ref{sec:proc_pid}, per cui si usa il
-valore nullo, che non è il \acr{pid} di nessun processo.
+valore nullo, che non è il \ids{PID} di nessun processo.
Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
sono già troppi processi nel sistema, il che di solito è sintomo che
si può dire quale processo fra il padre ed il figlio venga eseguito per primo
dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
primi due cicli sia stato eseguito per primo il padre (con la stampa del
-\acr{pid} del nuovo processo) per poi passare all'esecuzione del figlio
+\ids{PID} del nuovo processo) per poi passare all'esecuzione del figlio
(completata con i due avvisi di esecuzione ed uscita), e tornare
all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
dallo standard POSIX.1-2001.}
\begin{itemize*}
\item il valore di ritorno di \func{fork};
-\item il \acr{pid} (\textit{process id}), quello del figlio viene assegnato ad
+\item il \ids{PID} (\textit{process id}), quello del figlio viene assegnato ad
un nuovo valore univoco;
-\item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
- impostato al \acr{pid} del padre;
+\item il \ids{PPID} (\textit{parent process id}), quello del figlio viene
+ impostato al \ids{PID} del padre;
\item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
delle risorse usate (vedi sez.~\ref{sec:sys_resource_use}), che nel figlio
sono posti a zero;
\textsl{orfano}.
Questa complicazione viene superata facendo in modo che il processo orfano
-venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \acr{pid} 1,
+venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \ids{PID} 1,
cioè quello lanciato direttamente dal kernel all'avvio, che sta alla base
dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy} e che anche
per questo motivo ha un ruolo essenziale nel sistema e non può mai
fatale.}
Come già accennato quando un processo termina, il kernel controlla se è il
-padre di altri processi in esecuzione: in caso positivo allora il \acr{ppid}
-di tutti questi processi verrà sostituito dal kernel con il \acr{pid} di
+padre di altri processi in esecuzione: in caso positivo allora il \ids{PPID}
+di tutti questi processi verrà sostituito dal kernel con il \ids{PID} di
\cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel
caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo
stato di terminazione.
figli, tornando alla shell, che stampa il prompt sul terminale: circa due
secondi dopo viene stampato a video anche l'output dei tre figli che
terminano, e come si può notare in questo caso, al contrario di quanto visto
-in precedenza, essi riportano 1 come \acr{ppid}.
+in precedenza, essi riportano 1 come \ids{PPID}.
Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
perché non è detto che il padre possa ricevere immediatamente lo stato di
informazioni riguardo ai processi che sta terminando.
Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
-memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
+memorizzando alcuni dati essenziali, come il \ids{PID}, i tempi di CPU usati
dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente.
\fdecl{pid\_t wait(int *status)}
\fdesc{Attende la terminazione di un processo.}
}
-{La funzione ritorna il \acr{pid} del figlio in caso di successo e $-1$ per un
+{La funzione ritorna il \ids{PID} del figlio in caso di successo e $-1$ per un
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
variabile puntata da \param{status} e tutte le risorse del kernel relative al
processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate. Nel caso
un processo abbia più figli il valore di ritorno della funzione sarà impostato
-al \acr{pid} del processo di cui si è ricevuto lo stato di terminazione, cosa
+al \ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa
che permette di identificare qual è il figlio che è terminato.
\itindend{termination~status}
\fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
\fdesc{Attende il cambiamento di stato di un processo figlio.}
}
-{La funzione ritorna il \acr{pid} del processo che ha cambiato stato in caso
+{La funzione ritorna il \ids{PID} del processo che ha cambiato stato in caso
di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
assumerà uno dei valori:
\itindex{process~group} \textit{process group}
(vedi sez.~\ref{sec:sess_proc_group}) è
uguale a quello del processo chiamante.\\
- $>0$& -- & Attende per un figlio il cui \acr{pid} è uguale
+ $>0$& -- & Attende per un figlio il cui \ids{PID} è uguale
al valore di \param{pid}.\\
\hline
\end{tabular}
L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
funzione qualora nessun figlio sia uscito o non si siano verificate le altre
condizioni per l'uscita della funzione. in tal caso. In tal caso la funzione,
-invece di restituire il \acr{pid} del processo (che è sempre un intero
+invece di restituire il \ids{PID} del processo (che è sempre un intero
positivo) ritornerà un valore nullo.
Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono
che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la
gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}).
-Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \acr{pid},
+Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \ids{PID},
quando un processo figlio entra nello stato \textit{stopped}\footnote{in
realtà viene notificato soltanto il caso in cui il processo è stato fermato
da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
indefinito il comportamento di queste funzioni quando \signal{SIGCHLD} viene
ignorato.} indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno:
attendono la terminazione di un processo figlio e ritornano il relativo
-\acr{pid} e lo stato di terminazione nell'argomento \param{status}.
+\ids{PID} e lo stato di terminazione nell'argomento \param{status}.
In generale in un programma non si vuole essere forzati ad attendere la
conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
\hline
\hline
\const{P\_PID} & Indica la richiesta di attendere per un processo figlio
- il cui \acr{pid} corrisponda al valore dell'argomento
+ il cui \ids{PID} corrisponda al valore dell'argomento
\param{id}.\\
\const{P\_PGID}& Indica la richiesta di attendere per un processo figlio
appartenente al \textit{process group} (vedi
basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti
campi:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\var{si\_pid}] con il \acr{pid} del figlio.
+\item[\var{si\_pid}] con il \ids{PID} del figlio.
\item[\var{si\_uid}] con l'\textsl{user-ID reale} (vedi
sez.~\ref{sec:proc_perms}) del figlio.
\item[\var{si\_signo}] con \signal{SIGCHLD}.
processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
processo chiama una di queste funzioni esso viene completamente sostituito dal
-nuovo programma, il \acr{pid} del processo non cambia, dato che non viene
+nuovo programma, il \ids{PID} del processo non cambia, dato che non viene
creato un nuovo processo, la funzione semplicemente rimpiazza lo
\itindex{stack} \textit{stack}, i \index{segmento!dati} dati ed il
\index{segmento!testo} testo del processo corrente con un nuovo programma
sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
l'ambiente.
-Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da una
+Oltre a mantenere lo stesso \ids{PID}, il nuovo programma fatto partire da una
delle funzioni della famiglia \func{exec} mantiene la gran parte delle
proprietà del processo chiamante; una lista delle più significative è la
seguente:
\begin{itemize*}
-\item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
- (\acr{ppid});
+\item il \textit{process id} (\ids{PID}) ed il \textit{parent process id}
+ (\ids{PPID});
\item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
\textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
\item la directory radice e la directory di lavoro corrente (vedi
vari controlli di accesso.
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
-identificatori univoci, lo \textsl{user-ID} (abbreviato in \acr{uid}) ed il
-\textsl{group-ID} (abbreviato in \acr{gid}). Questi servono al kernel per
-identificare uno specifico utente o un gruppo di utenti, per poi poter
-controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
-esempio in sez.~\ref{sec:file_access_control} vedremo come ad ogni file
-vengano associati un utente ed un gruppo (i suoi \textsl{proprietari},
-indicati appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati
-dal kernel nella gestione dei permessi di accesso.
+identificatori univoci, lo \itindex{User~ID~(PID)} \textsl{User-ID}
+(abbreviato in \ids{UID}) ed il \itindex{Group~ID~(PID)} \textsl{Group-ID}
+(abbreviato in \ids{GID}). Questi servono al kernel per identificare uno
+specifico utente o un gruppo di utenti, per poi poter controllare che essi
+siano autorizzati a compiere le operazioni richieste. Ad esempio in
+sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano associati
+un utente ed un gruppo (i suoi \textsl{proprietari}, indicati appunto tramite
+un \ids{UID} ed un \ids{GID}) che vengono controllati dal kernel nella
+gestione dei permessi di accesso.
Dato che tutte le operazioni del sistema vengono compiute dai processi, è
evidente che per poter implementare un controllo sulle operazioni occorre
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
+ \begin{tabular}[c]{|c|c|l|p{7cm}|}
\hline
\textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
& \textbf{Significato} \\
\hline
\hline
- \acr{uid} & \textit{real} & \textsl{user-ID reale}
- & Indica l'utente che ha lanciato il programma.\\
- \acr{gid} & '' &\textsl{group-ID reale}
- & Indica il gruppo principale dell'utente che ha lanciato
- il programma.\\
+ \texttt{uid} & \textit{real} & \textsl{user-ID reale}
+ & Indica l'utente che ha lanciato il programma.\\
+ \texttt{gid} & '' &\textsl{group-ID reale}
+ & Indica il gruppo principale dell'utente che ha lanciato
+ il programma.\\
\hline
- \acr{euid} & \textit{effective} &\textsl{user-ID effettivo}
- & Indica l'utente usato nel controllo di accesso.\\
- \acr{egid} & '' & \textsl{group-ID effettivo}
- & Indica il gruppo usato nel controllo di accesso.\\
- -- & -- & \textsl{group-ID supplementari}
- & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
+ \texttt{euid}& \textit{effective} &\textsl{user-ID effettivo}
+ & Indica l'utente usato nel controllo di accesso.\\
+ \texttt{egid}& '' & \textsl{group-ID effettivo}
+ & Indica il gruppo usato nel controllo di accesso.\\
+ -- & -- & \textsl{group-ID supplementari}
+ & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
\hline
- -- & \textit{saved} & \textsl{user-ID salvato}
- & È una copia dell'\acr{euid} iniziale.\\
- -- & '' & \textsl{group-ID salvato}
- & È una copia dell'\acr{egid} iniziale.\\
+ -- & \textit{saved} & \textsl{user-ID salvato}
+ & Mantiene una copia dell'\acr{euid} iniziale.\\
+ -- & '' & \textsl{group-ID salvato}
+ & Mantiene una copia dell'\acr{egid} iniziale.\\
\hline
- \acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem}
- & Indica l'utente effettivo per l'accesso al filesystem. \\
- \acr{fsgid} & '' & \textsl{group-ID di filesystem}
- & Indica il gruppo effettivo per l'accesso al filesystem.\\
+ \texttt{fsuid}& \textit{filesystem} &\textsl{user-ID di filesystem}
+ & Indica l'utente effettivo per l'accesso al filesystem. \\
+ \texttt{fsgid}& '' & \textsl{group-ID di filesystem}
+ & Indica il gruppo effettivo per l'accesso al filesystem.\\
\hline
\end{tabular}
\caption{Identificatori di utente e gruppo associati a ciascun processo con
\label{tab:proc_uid_gid}
\end{table}
-Al primo gruppo appartengono l'\acr{uid} \textsl{reale} ed il \acr{gid}
+Al primo gruppo appartengono l'\ids{UID} \textsl{reale} ed il \ids{GID}
\textsl{reale}: questi vengono impostati al login ai valori corrispondenti
all'utente con cui si accede al sistema (e relativo gruppo principale).
Servono per l'identificazione dell'utente e normalmente non vengono mai
imposta questi identificatori ai valori corrispondenti all'utente che entra
nel sistema.
-Al secondo gruppo appartengono l'\acr{uid} \textsl{effettivo} e il \acr{gid}
-\textsl{effettivo}, a cui si aggiungono gli eventuali \acr{gid}
+Al secondo gruppo appartengono l'\ids{UID} \textsl{effettivo} e il \ids{GID}
+\textsl{effettivo}, a cui si aggiungono gli eventuali \ids{GID}
\textsl{supplementari} dei gruppi dei quali l'utente fa parte. Questi sono
invece gli identificatori usati nelle verifiche dei permessi del processo e
per il controllo di accesso ai file (argomento affrontato in dettaglio in
cui ci sia questa necessità, di dare a qualunque utente i privilegi o i
permessi di un altro, compreso l'amministratore.
-Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi
+Come nel caso del \ids{PID} e del \ids{PPID}, anche tutti questi
identificatori possono essere ottenuti da un programma attraverso altrettante
funzioni di lettura, queste sono \funcd{getuid}, \funcd{geteuid},
\funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono:
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{uid\_t getuid(void)}
-\fdesc{Legge l'\acr{uid} reale del processo corrente.}
+\fdesc{Legge l'\ids{UID} reale del processo corrente.}
\fdecl{uid\_t geteuid(void)}
-\fdesc{Legge l'\acr{uid} effettivo del processo corrente.}
+\fdesc{Legge l'\ids{UID} effettivo del processo corrente.}
\fdecl{gid\_t getgid(void)}
-\fdesc{Legge il \acr{gid} reale del processo corrente.}
+\fdesc{Legge il \ids{GID} reale del processo corrente.}
\fdecl{gid\_t getegid(void)}
-\fdesc{Legge il \acr{gid} effettivo del processo corrente.}
+\fdesc{Legge il \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano i rispettivi identificativi del processo corrente, e
non sono previste condizioni di errore.}
\end{funcproto}
-In generale l'uso di privilegi superiori, ottenibile con un \acr{uid}
+In generale l'uso di privilegi superiori, ottenibile con un \ids{UID}
\textsl{effettivo} diverso da quello reale, deve essere limitato il più
possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
un meccanismo che consenta ad un programma di rilasciare gli eventuali
migliorare la sicurezza con NFS (il \textit{Network File System}, protocollo
che consente di accedere ai file via rete).
-L'\acr{uid} \textsl{salvato} ed il \acr{gid} \textsl{salvato} sono copie
-dell'\acr{uid} \textsl{effettivo} e del \acr{gid} \textsl{effettivo} del
+L'\ids{UID} \textsl{salvato} ed il \ids{GID} \textsl{salvato} sono copie
+dell'\ids{UID} \textsl{effettivo} e del \ids{GID} \textsl{effettivo} del
processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del
-processo, come copie dell'\acr{uid} \textsl{effettivo} e del \acr{gid}
+processo, come copie dell'\ids{UID} \textsl{effettivo} e del \ids{GID}
\textsl{effettivo} dopo che questi sono stati impostati tenendo conto di
eventuali \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid}. Essi
quindi consentono di tenere traccia di quale fossero utente e gruppo effettivi
all'inizio dell'esecuzione di un nuovo programma.
-L'\acr{uid} \textsl{di filesystem} e il \acr{gid} \textsl{di filesystem} sono
+L'\ids{UID} \textsl{di filesystem} e il \ids{GID} \textsl{di filesystem} sono
un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
(torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
utente e gruppo di appartenenza) ad un processo sono rispettivamente
\funcd{setuid} e \funcd{setgid}; come accennato in
sez.~\ref{sec:proc_access_id} in Linux esse seguono la semantica POSIX che
-prevede l'esistenza dell'\acr{uid} salvato e del \acr{gid} salvato; i loro
+prevede l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato; i loro
prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int setuid(uid\_t uid)}
-\fdesc{Imposta l'\acr{uid} del processo corrente.}
+\fdesc{Imposta l'\ids{UID} del processo corrente.}
\fdecl{int setgid(gid\_t gid)}
-\fdesc{Imposta il \acr{gid} del processo corrente.}
+\fdesc{Imposta il \ids{GID} del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EPERM}.
Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
la prima, la seconda si comporta esattamente allo stesso modo facendo
-riferimento al \acr{gid} invece che all'\acr{uid}. Gli eventuali \acr{gid}
+riferimento al \ids{GID} invece che all'\ids{UID}. Gli eventuali \ids{GID}
supplementari non vengono modificati.
L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
-l'\acr{uid} effettivo è zero (cioè è quello dell'amministratore di sistema)
+l'\ids{UID} effettivo è zero (cioè è quello dell'amministratore di sistema)
allora tutti gli identificatori (\textit{real}, \textit{effective} e
\textit{saved}) vengono impostati al valore specificato da \param{uid},
-altrimenti viene impostato solo l'\acr{uid} effettivo, e soltanto se il valore
-specificato corrisponde o all'\acr{uid} reale o all'\acr{uid} salvato. Negli
+altrimenti viene impostato solo l'\ids{UID} effettivo, e soltanto se il valore
+specificato corrisponde o all'\ids{UID} reale o all'\ids{UID} salvato. Negli
altri casi viene segnalato un errore con \errcode{EPERM}.
Come accennato l'uso principale di queste funzioni è quello di poter
consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid} impostati (vedi
-sez.~\ref{sec:file_special_perm}) di riportare l'\acr{uid} effettivo a quello
+sez.~\ref{sec:file_special_perm}) di riportare l'\ids{UID} effettivo a quello
dell'utente che ha lanciato il programma, effettuare il lavoro che non
necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
situazione degli identificatori è la seguente:
\begin{eqnarray*}
\label{eq:1}
- \textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (del chiamante)} \\
\textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
\end{eqnarray*}
in tal caso infatti la situazione degli identificatori sarebbe:
\begin{eqnarray*}
\label{eq:2}
- \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
- \textsl{group-ID effettivo} &=& \textrm{\acr{gid}} \\
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
+ \textsl{group-ID effettivo} &=& \textrm{\ids{GID}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
\end{eqnarray*}
-e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
+e ogni processo lanciato dal terminale avrebbe comunque \ids{GID} come
\textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una
\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
funzione avrà successo e riporterà la situazione a:
\begin{eqnarray*}
\label{eq:3}
- \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
\textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
\end{eqnarray*}
processo, rendendo impossibile riguadagnare i privilegi di amministratore.
Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
crea una nuova shell per l'utente, ma quando si vuole cambiare soltanto
-l'\acr{uid} effettivo del processo per cedere i privilegi occorre
+l'\ids{UID} effettivo del processo per cedere i privilegi occorre
ricorrere ad altre funzioni.
Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int setreuid(uid\_t ruid, uid\_t euid)}
-\fdesc{Imposta \acr{uid} reale e \acr{uid} effettivo del processo corrente.}
+\fdesc{Imposta \ids{UID} reale e \ids{UID} effettivo del processo corrente.}
\fdecl{int setregid(gid\_t rgid, gid\_t egid)}
-\fdesc{Imposta \acr{gid} reale e \acr{gid} effettivo del processo corrente.}
+\fdesc{Imposta \ids{GID} reale e \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EPERM}.
\end{funcproto}
Le due funzioni sono identiche, quanto diremo per la prima riguardo gli
-\acr{uid} si applica alla seconda per i \acr{gid}. La funzione
-\func{setreuid} imposta rispettivamente l'\acr{uid} reale e l'\acr{uid}
+\ids{UID} si applica alla seconda per i \ids{GID}. La funzione
+\func{setreuid} imposta rispettivamente l'\ids{UID} reale e l'\ids{UID}
effettivo del processo corrente ai valori specificati da \param{ruid}
e \param{euid}. I processi non privilegiati possono impostare solo valori che
-corrispondano o al loro \acr{uid} effettivo o a quello reale o a quello
+corrispondano o al loro \ids{UID} effettivo o a quello reale o a quello
salvato, valori diversi comportano il fallimento della chiamata.
L'amministratore invece può specificare un valore qualunque. Specificando un
argomento di valore $-1$ l'identificatore corrispondente verrà lasciato
inalterato.
-Con queste funzioni si possono scambiare fra loro gli \acr{uid} reale ed
+Con queste funzioni si possono scambiare fra loro gli \ids{UID} reale ed
effettivo, e pertanto è possibile implementare un comportamento simile a
quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
scambio, e recuperandoli, una volta eseguito il lavoro non privilegiato, con
In questo caso però occorre porre molta attenzione quando si creano nuovi
processi nella fase intermedia in cui si sono scambiati gli identificatori, in
-questo caso infatti essi avranno un \acr{uid} reale privilegiato, che dovrà
+questo caso infatti essi avranno un \ids{UID} reale privilegiato, che dovrà
essere esplicitamente eliminato prima di porre in esecuzione un nuovo
programma, occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
-prima della \func{exec} per uniformare l'\acr{uid} reale a quello effettivo,
+prima della \func{exec} per uniformare l'\ids{UID} reale a quello effettivo,
perché in caso contrario il nuovo programma potrebbe a sua volta effettuare
uno scambio e riottenere dei privilegi non previsti.
Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
-si pone anche per l'\acr{uid} salvato. Ma la funzione \func{setreuid} deriva
+si pone anche per l'\ids{UID} salvato. Ma la funzione \func{setreuid} deriva
da un'implementazione di sistema che non ne prevede la presenza, e quindi non
è possibile usarla per correggere la situazione come nel caso precedente. Per
questo motivo in Linux tutte le volte che si imposta un qualunque valore
-diverso da quello dall'\acr{uid} reale corrente, l'\acr{uid} salvato viene
-automaticamente uniformato al valore dell'\acr{uid} effettivo.
+diverso da quello dall'\ids{UID} reale corrente, l'\ids{UID} salvato viene
+automaticamente uniformato al valore dell'\ids{UID} effettivo.
Altre due funzioni, \funcd{seteuid} e \funcd{setegid}, sono un'estensione
dello standard POSIX.1, ma sono comunque supportate dalla maggior parte degli
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int seteuid(uid\_t uid)}
-\fdesc{Imposta l'\acr{uid} effettivo del processo corrente.}
+\fdesc{Imposta l'\ids{UID} effettivo del processo corrente.}
\fdecl{int setegid(gid\_t gid)}
-\fdesc{Imposta il \acr{gid} effettivo del processo corrente.}
+\fdesc{Imposta il \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EPERM}.
\end{funcproto}
Ancora una volta le due funzioni sono identiche, e quanto diremo per la prima
-riguardo gli \acr{uid} si applica allo stesso modo alla seconda per i
-\acr{gid}. Con \func{seteuid} gli utenti normali possono impostare l'\acr{uid}
-effettivo solo al valore dell'\acr{uid} reale o dell'\acr{uid} salvato,
+riguardo gli \ids{UID} si applica allo stesso modo alla seconda per i
+\ids{GID}. Con \func{seteuid} gli utenti normali possono impostare l'\ids{UID}
+effettivo solo al valore dell'\ids{UID} reale o dell'\ids{UID} salvato,
l'amministratore può specificare qualunque valore. Queste funzioni sono usate
-per permettere all'amministratore di impostare solo l'\acr{uid} effettivo,
+per permettere all'amministratore di impostare solo l'\ids{UID} effettivo,
dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli
identificatori.
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)}
-\fdesc{Imposta l'\acr{uid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Imposta l'\ids{UID} reale, effettivo e salvato del processo corrente.}
\fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)}
-\fdesc{Imposta il \acr{gid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Imposta il \ids{GID} reale, effettivo e salvato del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EPERM}.
\end{funcproto}
Di nuovo le due funzioni sono identiche e quanto detto per la prima riguardo
-gli \acr{uid} si applica alla seconda per i \acr{gid}. La funzione
-\func{setresuid} imposta l'\acr{uid} reale, l'\acr{uid} effettivo e
-l'\acr{uid} salvato del processo corrente ai valori specificati
+gli \ids{UID} si applica alla seconda per i \ids{GID}. La funzione
+\func{setresuid} imposta l'\ids{UID} reale, l'\ids{UID} effettivo e
+l'\ids{UID} salvato del processo corrente ai valori specificati
rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}. I
-processi non privilegiati possono cambiare uno qualunque degli\acr{uid} solo
-ad un valore corrispondente o all'\acr{uid} reale, o a quello effettivo o a
+processi non privilegiati possono cambiare uno qualunque degli\ids{UID} solo
+ad un valore corrispondente o all'\ids{UID} reale, o a quello effettivo o a
quello salvato, l'amministratore può specificare i valori che vuole. Un valore
di $-1$ per un qualunque argomento lascia inalterato l'identificatore
corrispondente.
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)}
-\fdesc{Legge l'\acr{uid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Legge l'\ids{UID} reale, effettivo e salvato del processo corrente.}
\fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)}
-\fdesc{Legge il \acr{gid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Legge il \ids{GID} reale, effettivo e salvato del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EFAULT} se gli
Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
file per assumere l'identità del singolo utente remoto, ma se questo viene
-fatto cambiando l'\acr{uid} effettivo o l'\acr{uid} reale il server si espone
+fatto cambiando l'\ids{UID} effettivo o l'\ids{UID} reale il server si espone
alla ricezione di eventuali segnali ostili da parte dell'utente di cui ha
-temporaneamente assunto l'identità. Cambiando solo l'\acr{uid} di filesystem
+temporaneamente assunto l'identità. Cambiando solo l'\ids{UID} di filesystem
si ottengono i privilegi necessari per accedere ai file, mantenendo quelli
originari per quanto riguarda tutti gli altri controlli di accesso, così che
l'utente non possa inviare segnali al server NFS.
\begin{funcproto}{
\fhead{sys/fsuid.h}
\fdecl{int setfsuid(uid\_t fsuid)}
-\fdesc{Imposta l'\acr{uid} di filesystem del processo corrente.}
+\fdesc{Imposta l'\ids{UID} di filesystem del processo corrente.}
\fdecl{int setfsgid(gid\_t fsgid)}
-\fdesc{Legge il \acr{gid} di filesystem del processo corrente.}
+\fdesc{Legge il \ids{GID} di filesystem del processo corrente.}
}
{Le funzioni restituiscono il nuovo valore dell'identificativo in caso di
successo e quello corrente per un errore, in questo caso non viene però
La funzione legge gli identificatori dei gruppi supplementari del processo sul
vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è
-specificato se la funzione inserisca o meno nella lista il \acr{gid} effettivo
+specificato se la funzione inserisca o meno nella lista il \ids{GID} effettivo
del processo. Se si specifica un valore di \param{size} uguale a $0$ allora
l'argomento \param{list} non viene modificato, ma si ottiene il numero di
gruppi supplementari.
La funzione esegue una scansione del database dei gruppi (si veda
sez.~\ref{sec:sys_user_group}) per leggere i gruppi supplementari dell'utente
-specificato per nome (e non con un \acr{uid}) nella stringa passata con
+specificato per nome (e non con un \ids{UID}) nella stringa passata con
l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei
-\acr{gid} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
+\ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
che in ingresso deve indicare la dimensione di \param{group}, è passato come
\itindex{value~result~argument} \textit{value result argument} perché, qualora
il valore specificato sia troppo piccolo, la funzione ritorna $-1$, passando
La funzione esegue la scansione del database dei gruppi (usualmente
\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
-(di nuovo specificato per nome e non per \acr{uid}) con cui costruisce una
+(di nuovo specificato per nome e non per \ids{UID}) con cui costruisce una
lista di gruppi supplementari, a cui aggiunge anche
\param{group}, infine imposta questa lista per il processo corrente usando
\func{setgroups}. Si tenga presente che sia \func{setgroups} che
processo. Un utente normale infatti può modificare solo la priorità dei suoi
processi ed in genere soltanto diminuirla. Fino alla versione di kernel
2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
-sistemi derivati da SysV veniva richiesto che l'\acr{uid} reale o quello
-effettivo del processo chiamante corrispondessero all'\acr{uid} reale (e solo
+sistemi derivati da SysV veniva richiesto che l'\ids{UID} reale o quello
+effettivo del processo chiamante corrispondessero all'\ids{UID} reale (e solo
a quello) del processo di cui si intendeva cambiare la priorità. A partire
dalla versione 2.6.12 è stata adottata la semantica in uso presso i sistemi
derivati da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere
-anche con l'\acr{uid} effettivo.
+anche con l'\ids{UID} effettivo.
Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
ordinari poter aumentare la priorità dei propri processi specificando un
sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
assolute diverse da zero o politiche \const{SCHED\_FIFO} e
\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
-processi che gli appartengono; è cioè richiesto che l'\acr{uid} effettivo del
-processo chiamante corrisponda all'\acr{uid} reale o effettivo del processo
+processi che gli appartengono; è cioè richiesto che l'\ids{UID} effettivo del
+processo chiamante corrisponda all'\ids{UID} reale o effettivo del processo
indicato con \param{pid}.
Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
La funzione restituisce nell'argomento \param{tp} come una struttura
\struct{timespec}, (la cui definizione si può trovare in
fig.~\ref{fig:sys_timeval_struct}) il valore dell'intervallo di tempo usato
-per la politica \textit{round robin} dal processo indicato da \acr{pid}. Il
+per la politica \textit{round robin} dal processo indicato da \ids{PID}. Il
valore dipende dalla versione del kernel, a lungo infatti questo intervallo di
tempo era prefissato e non modificabile ad un valore di 150 millisecondi,
-restituito indipendentemente dal \acr{pid} indicato.
+restituito indipendentemente dal \ids{PID} indicato.
Con kernel recenti però è possibile ottenere una variazione della
\textit{time-slice}, modificando il valore di \textit{nice} del processo
dei processi che gli appartengono,\footnote{per la modifica delle priorità di
altri processi occorrono privilegi amministrativi, ed in particolare la
capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
-cioè quelli il cui \acr{uid} reale corrisponde all'\acr{uid} reale o effettivo
+cioè quelli il cui \ids{UID} reale corrisponde all'\ids{UID} reale o effettivo
del chiamante. Data la possibilità di ottenere un blocco totale del sistema,
solo l'amministratore\footnote{o un processo con la capacità
\const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
per sovrascriverne altri) viene cancellato quando si mette in esecuzione un
programma con i bit \acr{suid} e \acr{sgid} attivi (vedi
sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica
- degli \acr{uid} dei processi (vedi sez.~\ref{sec:proc_setuid}).
+ degli \ids{UID} dei processi (vedi sez.~\ref{sec:proc_setuid}).
L'operazione è stata introdotta a partire dal kernel 2.3.20, fino al kernel
2.6.12 e per i kernel successivi al 2.6.17 era possibile usare solo un
\item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali
\itindex{capabilities} \textit{capabilities} vengono cancellate quando si
- esegue un cambiamento di \acr{uid} del processo (per i dettagli si veda
+ esegue un cambiamento di \ids{UID} del processo (per i dettagli si veda
sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono
utilizzati soltanto se si sono specificati rispettivamente i flag
\const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e
-\const{CLONE\_CHILD\_CLEARTID}.
+\const{CLONE\_CHILD\_SETTID}.
+
+La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
+\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
+al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
+un processo.
Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
-nuovo processo da essa creato, è controllato dall'argomento \param{flags}, che
-deve essere specificato come maschera binaria, ottenuta con un OR aritmetico
-di una delle costanti del seguente elenco, che illustra quelle attualmente
-disponibili:\footnote{si fa riferimento al momento della stesura di questa
- sezione, cioè con il kernel 3.2.}
+nuovo processo da essa creato, è controllato principalmente
+dall'argomento \param{flags}, che deve essere specificato come maschera
+binaria, ottenuta con un OR aritmetico di una delle costanti del seguente
+elenco, che illustra quelle attualmente disponibili:\footnote{si fa
+ riferimento al momento della stesura di questa sezione, cioè con il kernel
+ 3.2.}
\begin{basedescript}{\desclabelstyle{\pushlabel}}
-\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il
+\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID}
\item[\const{CLONE\_CHILD\_SETTID}]
\item[\const{CLONE\_FILES}]
\item[\const{CLONE\_FS}]
esiste.}
\end{functions}
-La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
+La funzione \func{getpgid} permette di specificare il \ids{PID} del processo
di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
equivalente a \code{getpgid(0)}.
Ciascun raggruppamento di processi ha sempre un processo principale, il
cosiddetto \itindex{process~group~leader} \textit{process group leader}, che è
-identificato dall'avere un \acr{pgid} uguale al suo \acr{pid}, in genere
+identificato dall'avere un \acr{pgid} uguale al suo \ids{PID}, in genere
questo è il primo processo del raggruppamento, che si incarica di lanciare
tutti gli altri. Un nuovo raggruppamento si crea con la funzione
\funcd{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD definisce
richiedere esplicitamente la compatibilità all'indietro con BSD, definendo
la macro \macro{\_BSD\_SOURCE}.} il cui prototipo è:
\begin{prototype}{unistd.h}{int setpgrp(void)}
- Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
+ Modifica il \acr{pgid} al valore del \ids{PID} del processo corrente.
\bodydesc{La funzione restituisce il valore del nuovo \textit{process
group}.}
\end{prototype}
-La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
+La funzione, assegnando al \acr{pgid} il valore del \ids{PID} processo
corrente, rende questo \itindex{process~group~leader} \textit{group leader} di
un nuovo raggruppamento, tutti i successivi processi da esso creati
apparterranno (a meno di non cambiare di nuovo il \acr{pgid}) al nuovo
dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
\struct{task\_struct}.} Specificando un valore nullo per \param{pid} si
indica il processo corrente, mentre specificando un valore nullo per
-\param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del
+\param{pgid} si imposta il \textit{process group} al valore del \ids{PID} del
processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
0)}.
\bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
errore, il solo errore possibile è \errval{EPERM}, che si ha quando il
- \acr{pgid} e \acr{pid} del processo coincidono.}
+ \acr{pgid} e \ids{PID} del processo coincidono.}
\end{prototype}
La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
-valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
+valore del suo \ids{PID}, creando così una nuova sessione ed un nuovo
\textit{process group} di cui esso diventa leader (come per i \textit{process
group} un processo si dice leader di sessione\footnote{in Linux la proprietà
è mantenuta in maniera indipendente con un apposito campo \var{leader} in
- \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed
+ \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \ids{PID}) ed
unico componente. Inoltre la funzione distacca il processo da ogni terminale
di controllo (torneremo sull'argomento in sez.~\ref{sec:sess_ctrl_term}) cui
fosse in precedenza associato.
\itindex{process~group~leader} leader di un \textit{process group}, per cui
per usarla di norma si esegue una \func{fork} e si esce, per poi chiamare
\func{setsid} nel processo figlio, in modo che, avendo questo lo stesso
-\acr{pgid} del padre ma un \acr{pid} diverso, non ci siano possibilità di
+\acr{pgid} del padre ma un \ids{PID} diverso, non ci siano possibilità di
errore.\footnote{potrebbe sorgere il dubbio che, per il riutilizzo dei valori
- dei \acr{pid} fatto nella creazione dei nuovi processi (vedi
+ dei \ids{PID} fatto nella creazione dei nuovi processi (vedi
sez.~\ref{sec:proc_pid}), il figlio venga ad assumere un valore
corrispondente ad un \textit{process group} esistente; questo viene evitato
- dal kernel che considera come disponibili per un nuovo \acr{pid} solo valori
- che non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{sid} in uso nel
+ dal kernel che considera come disponibili per un nuovo \ids{PID} solo valori
+ che non corrispondono ad altri \ids{PID}, \acr{pgid} o \acr{sid} in uso nel
sistema.} Questa funzione viene usata di solito nel processo di login (per i
dettagli vedi sez.~\ref{sec:sess_login}) per raggruppare in una sessione tutti
i comandi eseguiti da un utente dalla sua shell.
\texttt{HOME}, \texttt{SHELL}, ecc. Infine attraverso l'uso di \func{setuid},
\func{setgid} e \func{initgroups} verrà cambiata l'identità del proprietario
del processo, infatti, come spiegato in sez.~\ref{sec:proc_setuid}, avendo
-invocato tali funzioni con i privilegi di amministratore, tutti gli \acr{uid}
-ed i \acr{gid} (reali, effettivi e salvati) saranno impostati a quelli
+invocato tali funzioni con i privilegi di amministratore, tutti gli \ids{UID}
+ed i \ids{GID} (reali, effettivi e salvati) saranno impostati a quelli
dell'utente.
A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
\item Eseguire una \func{fork} e terminare immediatamente il processo padre
proseguendo l'esecuzione nel figlio. In questo modo si ha la certezza che
il figlio non è un \itindex{process~group~leader} \textit{process group
- leader}, (avrà il \acr{pgid} del padre, ma un \acr{pid} diverso) e si può
+ leader}, (avrà il \acr{pgid} del padre, ma un \ids{PID} diverso) e si può
chiamare \func{setsid} con successo. Inoltre la shell considererà terminato
il comando all'uscita del padre.
\item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo
sistema del \textit{syslog}.\\
\const{LOG\_PERROR} & Stampa anche su \file{stderr} (non previsto in
POSIX.1-2001).\\
-\const{LOG\_PID} & Inserisce nei messaggi il \acr{pid} del processo
+\const{LOG\_PID} & Inserisce nei messaggi il \ids{PID} del processo
chiamante.\\
\hline
\end{tabular}
non viene inviato nessun segnale, ma viene eseguito il controllo degli errori,
in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste.
-Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in
+Si tenga conto però che il sistema ricicla i \ids{PID} (come accennato in
sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
esso sia realmente quello a cui si intendeva mandare il segnale.
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- $>0$ & Il segnale è mandato al processo con il \acr{pid} indicato.\\
+ $>0$ & Il segnale è mandato al processo con il \ids{PID} indicato.\\
0 & Il segnale è mandato ad ogni processo del \itindex{process~group}
\textit{process group} del chiamante.\\
$-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
\end{table}
Solo l'amministratore può inviare un segnale ad un processo qualunque, in
-tutti gli altri casi l'\acr{uid} reale o l'\acr{uid} effettivo del processo
-chiamante devono corrispondere all'\acr{uid} reale o all'\acr{uid} salvato
+tutti gli altri casi l'\ids{UID} reale o l'\ids{UID} effettivo del processo
+chiamante devono corrispondere all'\ids{UID} reale o all'\ids{UID} salvato
della destinazione. Fa eccezione il caso in cui il segnale inviato sia
\signal{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
In particolare i campi utilizzati dai segnali \textit{real-time} sono
\var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il
-\acr{pid} e l'\acr{uid} effettivo del processo che ha inviato il segnale, mentre
+\ids{PID} e l'\ids{UID} effettivo del processo che ha inviato il segnale, mentre
per la restituzione dei dati viene usato il campo \var{si\_value}.
\begin{figure}[!htb]
\hline
\hline
\texttt{passwd} & Corrispondenze fra nome dell'utente e relative
- proprietà (\acr{uid}, gruppo principale, ecc.).\\
+ proprietà (\ids{UID}, gruppo principale, ecc.).\\
\texttt{shadow} & Corrispondenze fra username e password dell'utente
(e altre informazioni relative alle password).\\
\texttt{group} & Corrispondenze fra nome del gruppo e proprietà dello
\signal{SIGURG} quando viene completata una operazione di I/O asincrono o
arrivano dei dati urgenti \itindex{out-of-band} (\texttt{out-of-band}). Il
terzo argomento deve essere un puntatore ad una variabile di tipo
- \type{pid\_t}; un valore positivo indica direttamente il \acr{pid} del
+ \type{pid\_t}; un valore positivo indica direttamente il \ids{PID} del
processo, mentre un valore negativo indica (col valore assoluto) il
\textit{process group}. Senza privilegi di amministratore o la capability
\const{CAP\_KILL} si può impostare solo se stessi o il proprio
Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
dall'utente generico, ad esempio in generale tutti i socket di tipo
\const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
-di amministratore (cioè con \acr{uid} effettivo uguale a zero) o dotati della
+di amministratore (cioè con \ids{UID} effettivo uguale a zero) o dotati della
\itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
-soltanto processi con i privilegi di amministratore (con \acr{uid} effettivo
+soltanto processi con i privilegi di amministratore (con \ids{UID} effettivo
uguale a zero) o con la \itindex{capabilities} \textit{capability}
\const{CAP\_NET\_BIND\_SERVICE} possono usare la funzione \func{bind} (che
vedremo in sez.~\ref{sec:TCP_func_bind}) su queste porte.
speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
di questi socket è una operazione privilegiata e può essere effettuati solo da
-un processo con i privilegi di amministratore (\acr{uid} effettivo nullo) o con
+un processo con i privilegi di amministratore (\ids{UID} effettivo nullo) o con
la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo
\conffile{/etc/gshadow}, in cui sono state spostate le informazioni di
autenticazione (ed inserite alcune estensioni) per toglierle dagli altri
file che devono poter essere letti per poter effettuare l'associazione fra
- username e \acr{uid}.} il cui formato è descritto dalle relative pagine del
+ username e \ids{UID}.} il cui formato è descritto dalle relative pagine del
manuale\footnote{nella quinta sezione, quella dei file di configurazione,
occorre cioè usare \cmd{man 5 passwd} dato che altrimenti si avrebbe la
pagina di manuale del comando \cmd{passwd}.} e tutte le funzioni che
% \acr{glibc} per modularizzare l'accesso a tutti i servizi in cui sia
% necessario trovare una corrispondenza fra un nome ed un numero (od altra
% informazione) ad esso associato, come appunto, quella fra uno username ed un
-% \acr{uid} o fra un \acr{gid} ed il nome del gruppo corrispondente.
+% \ids{UID} o fra un \ids{GID} ed il nome del gruppo corrispondente.
Le prime funzioni che vedremo sono quelle previste dallo standard POSIX.1;
queste sono del tutto generiche e si appoggiano direttamente al \textit{Name
Service Switch}, per cui sono in grado di ricevere informazioni qualunque
Le due funzioni forniscono le informazioni memorizzate nel registro degli
utenti (che nelle versioni più recenti possono essere ottenute attraverso PAM)
-relative all'utente specificato attraverso il suo \acr{uid} o il nome di
+relative all'utente specificato attraverso il suo \ids{UID} o il nome di
login. Entrambe le funzioni restituiscono un puntatore ad una struttura di
tipo \struct{passwd} la cui definizione (anch'essa eseguita in \file{pwd.h}) è
riportata in fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente
\file{/var/log/btmp} dove invece vengono memorizzati dal programma di login
tutti tentativi di accesso fallito.} Quando un utente si collega viene
aggiunta una voce a \file{/var/run/utmp} in cui viene memorizzato il nome di
-login, il terminale da cui ci si collega, l'\acr{uid} della shell di login,
+login, il terminale da cui ci si collega, l'\ids{UID} della shell di login,
l'orario della connessione ed altre informazioni. La voce resta nel file fino
al logout, quando viene cancellata e spostata in \file{/var/log/wtmp}.
projects / gapil.git / commitdiff