Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si
suole chiamare questo tipo di associazione un collegamento diretto (o
\textit{hard link}). Il prototipo della funzione e le sue caratteristiche
-principali, come risultano dalla man page, sono le seguenti:
+principali, come risultano dalla pagina di manuale, sono le seguenti:
\begin{prototype}{unistd.h}
{int link(const char *oldpath, const char *newpath)}
Crea un nuovo collegamento diretto al file indicato da \var{oldpath}
\param{oldpath}.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso la variabile \var{errno} restituisce i valori:
+ errore, nel qual caso la variabile \var{errno} assumerà i valori:
\begin{errlist}
\item[\macro{EPERM}] il filesystem che contiene \param{newpath} non supporta
i link simbolici.
\textit{dangling link}, letteralmente un \textsl{link ciondolante}.
Come accennato i link simbolici sono risolti automaticamente dal kernel
-all'invocazione delle varie system call; in \ntab\ si è riportato un elenco
-dei comportamenti delle varie funzioni di libreria che operano sui file nei
-confronti della risoluzione dei link simbolici, specificando quali seguono il
-link simbolico e quali invece possono operare direttamente sul suo contenuto.
+all'invocazione delle varie system call; in \tabref{tab:file_symb_effect} si è
+riportato un elenco dei comportamenti delle varie funzioni di libreria che
+operano sui file nei confronti della risoluzione dei link simbolici,
+specificando quali seguono il link simbolico e quali invece possono operare
+direttamente sul suo contenuto.
\begin{table}[htb]
\centering
\footnotesize
\bodydesc{La funzione restituisce il numero di caratteri letti dentro
\var{buff} o -1 per un errore, nel qual caso la variabile
- \var{errno} viene impostata a:
+ \var{errno} assumerà i valori:
\begin{errlist}
\item[\macro{EINVAL}] \param{path} non è un link simbolico o \param{size}
non è positiva.
\begin{figure}[htb]
\centering
- \includegraphics[width=7cm]{img/link_loop}
+ \includegraphics[width=9cm]{img/link_loop}
\caption{Esempio di loop nel filesystem creato con un link simbolico.}
\label{fig:file_link_loop}
\end{figure}
Un caso comune che si può avere con i link simbolici è la creazione dei
-cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta
-la struttura della directory \file{/boot}. Come si vede si è creato al suo
-interno un link simbolico che punta di nuovo a \file{/boot}.\footnote{Questo
- tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
- bootloader in grado di leggere direttamente da vari filesystem il file da
- lanciare come sistema operativo) di vedere i file in questa directory con lo
- stesso path con cui verrebbero visti dal sistema operativo, anche se essi si
- trovano, come è solito, su una partizione separata (e che \cmd{grub}
- vedrebbe come radice).}
+cosiddetti \textit{loop}. La situazione è illustrata in
+\figref{fig:file_link_loop}, che riporta la struttura della directory
+\file{/boot}. Come si vede si è creato al suo interno un link simbolico che
+punta di nuovo a \file{/boot}.\footnote{Questo tipo di loop è stato effettuato
+ per poter permettere a \cmd{grub} (un bootloader in grado di leggere
+ direttamente da vari filesystem il file da lanciare come sistema operativo)
+ di vedere i file in questa directory con lo stesso path con cui verrebbero
+ visti dal sistema operativo, anche se essi si trovano, come è solito, su una
+ partizione separata (e che \cmd{grub} vedrebbe come radice).}
Questo può causare problemi per tutti quei programmi che effettuano la
scansione di una directory senza tener conto dei link simbolici, ad esempio se
\begin{errlist}
\item[\macro{EPERM}] Il filesystem non supporta la cancellazione di
directory, oppure la directory che contiene \var{dirname} ha lo sticky bit
- impostato e l'\textit{effective user id} del processo non corrisponde al
+ impostato e l'userid effettivo del processo non corrisponde al
proprietario della directory.
\item[\macro{EACCESS}] Non c'è il permesso di scrittura per la directory che
contiene la directory che si vuole cancellare, o non c'è il permesso di
Cambia la directory di lavoro corrente in \param{pathname}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
- nel qual caso \var{errno} viene impostata a:
+ nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\macro{ENOTDIR}] Non si è specificata una directory.
\item[\macro{EACCESS}] Manca il permesso di ricerca su uno dei componenti di
pathname.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, in caso di errore \var{errno} viene impostata ai valori
- \macro{EBADF} o \macro{EACCES}.}
+ errore, in caso di errore \var{errno} assumerà i valori \macro{EBADF} o
+ \macro{EACCES}.}
\end{prototype}
\noindent anche in questo caso \param{fd} deve essere un file descriptor
valido che fa riferimento ad una directory. Inoltre l'unico errore di accesso
\bodydesc{La funzione ritorna il puntatore allo stream associato al file
temporaneo in caso di successo e \macro{NULL} in caso di errore, nel qual
- caso \var{errno} viene impostata a
+ caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
\item[\macro{EEXIST}] Non è stato possibile generare un nome univoco.
\param{template}.
\bodydesc{La funzione ritorna il puntatore \param{template} in caso di
- successo e \macro{NULL} in caso di errore, nel qual caso \var{errno} viene
- impostata a:
+ successo e \macro{NULL} in caso di errore, nel qual caso \var{errno}
+ assumerà i valori:
\begin{errlist}
\item[\macro{EINVAL}] \param{template} non termina con \code{XXXXXX}.
\end{errlist}}
finali di \param{template}.
\bodydesc{La funzione ritorna il file descriptor in caso successo e
- -1 in caso di errore, nel qual caso \var{errno} viene impostata a:
+ -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\macro{EINVAL}] \param{template} non termina con \code{XXXXXX}.
\item[\macro{EEXIST}] non è riuscita a creare un file temporano, il
\code{XXXXXX} finali di \param{template}.
\bodydesc{La funzione ritorna il puntatore al nome della directory in caso
- successo e \macro{NULL} in caso di errore, nel qual caso \var{errno} viene
- impostata a:
+ successo e \macro{NULL} in caso di errore, nel qual caso \var{errno}
+ assumerà i valori:
\begin{errlist}
\item[\macro{EINVAL}] \param{template} non termina con \code{XXXXXX}.
\end{errlist}
eccetto che si usa con un file aperto, specificato tramite il suo file
descriptor \var{filedes}.
- \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
- un errore, in caso di errore \var{errno} può assumere uno dei
- valori: \macro{EBADF}, \macro{ENOENT}, \macro{ENOTDIR},
- \macro{ELOOP}, \macro{EFAULT}, \macro{EACCESS}, \macro{ENOMEM},
- \macro{ENAMETOOLONG}.}
+ \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
+ errore, nel qual caso \var{errno} assumerà uno dei valori: \macro{EBADF},
+ \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP}, \macro{EFAULT},
+ \macro{EACCESS}, \macro{ENOMEM}, \macro{ENAMETOOLONG}.}
\end{functions}
\noindent il loro comportamento è identico, solo che operano rispettivamente
su un file, su un link simbolico e su un file descriptor.
La struttura \var{stat} usata da queste funzioni è definita nell'header
\file{sys/stat.h} e in generale dipende dall'implementazione, la versione
-usata da Linux è mostrata in \nfig, così come riportata dalla man page di
-\func{stat} (in realtà la definizione effettivamente usata nel kernel dipende
-dall'architettura e ha altri campi riservati per estensioni come tempi più
-precisi, o per il padding dei campi).
+usata da Linux è mostrata in \figref{fig:file_stat_struct}, così come
+riportata dalla pagina di manuale di \func{stat} (in realtà la definizione
+effettivamente usata nel kernel dipende dall'architettura e ha altri campi
+riservati per estensioni come tempi più precisi, o per il padding dei campi).
\begin{figure}[!htb]
\footnotesize
\centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct stat {
dev_t st_dev; /* device */
ino_t st_ino; /* inode */
\label{fig:file_stat_struct}
\end{figure}
-Si noti come i vari membri della struttura siano specificati come tipi nativi
-del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
-\file{sys/types.h}).
+Si noti come i vari membri della struttura siano specificati come tipi
+primitivi del sistema (di quelli definiti in
+\tabref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
\subsection{I tipi di file}
queste vengono usate anche da Linux che supporta pure le estensioni allo
standard per i link simbolici e i socket definite da BSD; l'elenco completo
delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
-riportato in \ntab.
+riportato in \tabref{tab:file_type_macro}.
\begin{table}[htb]
\centering
\footnotesize
Oltre alle macro di \tabref{tab:file_type_macro} è possibile usare
direttamente il valore di \var{st\_mode} per ricavare il tipo di file
controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
-\file{sys/stat.h} sono definite le costanti numeriche riportate in \ntab.
+\file{sys/stat.h} sono definite le costanti numeriche riportate in
+\tabref{tab:file_mode_flags}.
-Il primo valore dell'elenco di \secref{tab:file_mode_flags} è la maschera
+Il primo valore dell'elenco di \tabref{tab:file_mode_flags} è la maschera
binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
possono essere usati per effettuare la selezione sul tipo di file voluto, con
nell'inode insieme agli altri attributi del file e possono essere letti
tramite la funzione \func{stat}, che li restituisce attraverso tre campi della
struttura \var{stat} di \figref{fig:file_stat_struct}. Il significato di detti
-tempi e dei relativi campi è riportato nello schema in \ntab, dove si è anche
-riportato un esempio delle funzioni che effettuano cambiamenti su di essi.
+tempi e dei relativi campi è riportato nello schema in
+\tabref{tab:file_file_times}, dove si è anche riportato un esempio delle
+funzioni che effettuano cambiamenti su di essi.
\begin{table}[htb]
\centering
tempo di cambiamento di stato) per decidere quali file devono essere
archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni
\cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato
-nell'ultima colonna di \curtab.
+nell'ultima colonna di \tabref{tab:file_file_times}.
L'effetto delle varie funzioni di manipolazione dei file sui tempi è
-illustrato in \ntab. Si sono riportati gli effetti sia per il file a cui si fa
-riferimento, sia per la directory che lo contiene; questi ultimi possono
-essere capiti se si tiene conto di quanto già detto, e cioè che anche le
-directory sono file (che contengono una lista di nomi) che il sistema tratta
-in maniera del tutto analoga a tutti gli altri.
+illustrato in \tabref{tab:file_times_effects}. Si sono riportati gli effetti
+sia per il file a cui si fa riferimento, sia per la directory che lo contiene;
+questi ultimi possono essere capiti se si tiene conto di quanto già detto, e
+cioè che anche le directory sono file (che contengono una lista di nomi) che
+il sistema tratta in maniera del tutto analoga a tutti gli altri.
Per questo motivo tutte le volte che compiremo un'operazione su un file che
comporta una modifica del nome contenuto nella directory, andremo anche a
\param{filename} secondo i campi \var{actime} e \var{modtime} di
\param{times}. Se questa è \macro{NULL} allora viene usato il tempo corrente.
-\bodydesc{La funzione restituisce zero in caso di successo e -1 in caso
- di errore, nel qual caso \var{errno} è impostata opportunamente.
-\begin{errlist}
-\item[\macro{EACCESS}] non si ha il permesso di scrittura sul file.
-\item[\macro{ENOENT}] \param{filename} non esiste.
-\end{errlist}}
+\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\macro{EACCESS}] non si ha il permesso di scrittura sul file.
+ \item[\macro{ENOENT}] \param{filename} non esiste.
+ \end{errlist}}
\end{prototype}
-La struttura \var{utimebuf} usata da \func{utime} è definita come:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+La funzione prende come argomento \param{times} una struttura \var{utimebuf},
+la cui definizione è riportata in \figref{fig:struct_utimebuf}, con la quale
+si possono specificare i nuovi valori che si vogliono impostare per tempi.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct utimbuf {
time_t actime; /* access time */
time_t modtime; /* modification time */
};
-\end{lstlisting}
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \type{utimbuf}, usata da \func{utime} per modificare i
+ tempi dei file.}
+ \label{fig:struct_utimebuf}
+\end{figure}
L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
cosa è l'argomento \param{times}; se è \macro{NULL} la funzione imposta il
volte che si modifica l'inode (quindi anche alla chiamata di \func{utime}).
Questo serve anche come misura di sicurezza per evitare che si possa
modificare un file nascondendo completamente le proprie tracce. In realtà la
-cosa resta possibile, se si è in grado di accedere al device, scrivendo
-direttamente sul disco senza passare attraverso il filesystem, ma ovviamente
-in questo modo la cosa è molto più complicata da realizzare.
+cosa resta possibile, se si è in grado di accedere al file di dispositivo,
+scrivendo direttamente sul disco senza passare attraverso il filesystem, ma
+ovviamente in questo modo la cosa è molto più complicata da realizzare.
si parla dei permessi base come di permessi per \textit{owner}, \textit{group}
ed \textit{all}, le cui iniziali possono dar luogo a confusione. Le costanti
che permettono di accedere al valore numerico di questi bit nel campo
-\var{st\_mode} sono riportate in \ntab.
+\var{st\_mode} sono riportate in \tabref{tab:file_bit_perm}.
\begin{table}[htb]
\centering
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'\textit{effective user id},
-l'\textit{effective group id} e gli eventuali \textit{supplementary group id}
-del processo.\footnote{in realtà Linux per quanto riguarda l'accesso ai file
- utilizza al posto degli \textit{effective id} i \textit{filesystem id} (si
- veda \secref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai
- primi, eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo
- questa differenza.}
+\var{st\_gid} accennati in precedenza) e l'userid effettivo, il groupid
+effettivo e gli eventuali groupid supplementari del processo.\footnote{in
+ realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli gli
+ identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
+ \secref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
+ eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo questa
+ differenza.}
Per una spiegazione dettagliata degli identificatori associati ai processi si
veda \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in
-\secref{sec:file_suid_sgid}, l'\textit{effective user id} e
-l'\textit{effective group id} corrispondono a \acr{uid} e \acr{gid}
-dell'utente che ha lanciato il processo, mentre i \textit{supplementary group
- id} sono quelli dei gruppi cui l'utente appartiene.
+\secref{sec:file_suid_sgid}, l'userid effettivo e il groupid effectivo
+corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
+lanciato il processo, mentre i groupid 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'\textit{effective user id} del processo è zero (corrispondente
+\item Se l'userid 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'\textit{effective user id} del processo è uguale all'\acr{uid} del
+\item Se l'userid effettivo del processo è uguale all'\acr{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 l'\textit{effective group id} del processo o uno dei
- \textit{supplementary group id} dei processi corrispondono al \acr{gid} del
- file allora:
+\item Se il groupid effettivo del processo o uno dei groupid supplementari dei
+ processi corrispondono al \acr{gid} del file allora:
\begin{itemize*}
\item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
consentito,
\macro{S\_ISUID} e \macro{S\_ISGID}.
Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
-programma il comportamento normale del kernel è quello di impostare
-l'\textit{effective user id} e l'\textit{effective group id} del nuovo
-processo all'\acr{uid} e al \acr{gid} del processo corrente, che normalmente
+programma il comportamento normale del kernel è quello di impostare gli
+identificatori del gruppo \textit{effective} del nuovo processo al valore dei
+corrispondenti del gruppo \textit{real} del processo corrente, che normalmente
corrispondono dell'utente con cui si è entrati nel sistema.
Se però il file del programma\footnote{per motivi di sicurezza il kernel
ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili.} (che
ovviamente deve essere eseguibile) ha il bit \acr{suid} impostato, il kernel
-assegnerà come \textit{effective user id} 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 sull'\textit{effective group
- id} del processo.
+assegnerà come userid 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 groupid effettivo del processo.
I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
di usare programmi che abbisognano di privilegi speciali; l'esempio classico è
\secref{sec:file_dir_creat_rem}).
Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
-all'\textit{effective user id} del processo che lo crea; per il \acr{gid}
-invece prevede due diverse possibilità:
+all'userid effettivo del processo che lo crea; per il \acr{gid} invece prevede
+due diverse possibilità:
\begin{itemize*}
-\item il \acr{gid} del file corrisponde all'\textit{effective group id} del
- processo.
+\item il \acr{gid} del file corrisponde al group id effettivo del processo.
\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
esso è creato.
\end{itemize*}
\label{sec:file_access}
Come visto in \secref{sec:file_access_control} il controllo di accesso ad un
-file viene fatto usando \textit{effective user id} e \textit{effective group
- id} del processo; ma ci sono casi in cui è necessario effettuare il
-controllo usando il \textit{real user id} ed il \textit{real group id} (cioè
-\acr{uid} e \acr{gid} dell'utente che ha lanciato il programma, e che, come
-accennato in \secref{sec:file_suid_sgid} e spiegato in
-\secref{sec:proc_perms}, non è detto siano uguali agli \textit{effective id}).
-Per far questo si può usare la funzione \func{access}, il cui prototipo è:
+file viene fatto utilizzando l'userid ed il groupid effettivo del processo; ci
+sono casi però in cui si può voler effettuare il controllo con l'userid reale
+ed il groupid reale, vale a dire usando i valori di \acr{uid} e \acr{gid}
+relativi all'utente che ha lanciato il programma, e che, come accennato in
+\secref{sec:file_suid_sgid} e spiegato in dettaglio in
+\secref{sec:proc_perms}, non è detto siano uguali a quelli effettivi. Per far
+questo si può usare la funzione \func{access}, il cui prototipo è:
\begin{prototype}{unistd.h}
{int access(const char *pathname, int mode)}
-Verifica i permessi di accesso, indicati da \var{mode}, per il file indicato
-da \var{pathname}.
+Verifica i permessi di accesso, indicati da \param{mode}, per il file indicato
+da \param{pathname}.
-\bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
- quest'ultimo caso la variabile \var{errno} viene impostata secondo i codici di
- errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL},
- \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP},
- \macro{EIO}.}
+\bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
+ è consentito ed in caso di errore; nel qual caso la variabile \var{errno}
+ assumerà i valori:
+ \begin{errlist}
+ \item[\macro{EINVAL}] il valore di \param{mode} non è valido.
+ \item[\macro{EACCES}] l'accesso al file non è consentito, o non si ha il
+ permesso di attraversare una delle directory di \param{pathname}.
+ \item[\macro{EROFS}] si è richiesto l'accesso in scrittura per un file su un
+ filesystem montato in sola lettura.
+ \end{errlist}
+ ed inoltre \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT},
+ \macro{ENOTDIR}, \macro{ELOOP}, \macro{EIO}.}
\end{prototype}
I valori possibili per l'argomento \param{mode} sono esprimibili come
-combinazione delle costanti numeriche riportate in \ntab\ (attraverso un OR
-binario). I primi tre valori implicano anche la verifica dell'esistenza del
-file, se si vuole verificare solo quest'ultima si può usare \macro{F\_OK}, o
-anche direttamente \func{stat}. In caso \var{pathname} si riferisca ad un link
-simbolico il controllo è fatto sul file a cui esso fa riferimento.
+combinazione delle costanti numeriche riportate in
+\tabref{tab:file_access_mode_val} (attraverso un OR binario delle stesse). I
+primi tre valori implicano anche la verifica dell'esistenza del file, se si
+vuole verificare solo quest'ultima si può usare \macro{F\_OK}, o anche
+direttamente \func{stat}. Nel caso in cui \var{pathname} si riferisca ad un
+link simbolico, questo viene seguito ed il controllo è fatto sul file a cui
+esso fa riferimento.
La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
fatto che una directory abbia permesso di scrittura non significa che ci si
\end{table}
Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
-eseguendo un programma coi privilegi di un altro utente (ad esmepio attraverso
+eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso
l'uso del \acr{suid} bit) che vuole controllare se l'utente originale ha i
permessi per accedere ad un certo file.
\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[\macro{EPERM}] L'\textit{effective user id} non corrisponde a quello
- del proprietario del file o non è zero.
+ \item[\macro{EPERM}] L'userid effettivo non corrisponde a quello del
+ proprietario del file o non è zero.
\end{errlist}
ed inoltre \macro{EROFS} e \macro{EIO}; \func{chmod} restituisce anche
\macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM},
\macro{EBADF}.}
\end{functions}
-I valori possibili per \var{mode} sono indicati in \ntab. I valori possono
-esser combinati con l'OR binario delle relative costanti simboliche, o
-specificati direttamente, come per l'analogo comando di shell, con il valore
-numerico (la shell lo vuole in ottale, dato che i bit dei permessi sono
-divisibili in gruppi di tre). Ad esempio i permessi standard assegnati ai
-nuovi file (lettura e scrittura per il proprietario, sola lettura per il
-gruppo e gli altri) sono corrispondenti al valore ottale $0644$, un programma
-invece avrebbe anche il bit di esecuzione attivo, con un valore di $0755$, se
-si volesse attivare il bit \acr{suid} il valore da fornire sarebbe $4755$.
+I valori possibili per \var{mode} sono indicati in
+\tabref{tab:file_permission_const}. I valori possono esser combinati con l'OR
+binario delle relative costanti simboliche, o specificati direttamente, come
+per l'analogo comando di shell, con il valore numerico (la shell lo vuole in
+ottale, dato che i bit dei permessi sono divisibili in gruppi di tre). Ad
+esempio i permessi standard assegnati ai nuovi file (lettura e scrittura per
+il proprietario, sola lettura per il gruppo e gli altri) sono corrispondenti
+al valore ottale $0644$, un programma invece avrebbe anche il bit di
+esecuzione attivo, con un valore di $0755$, se si volesse attivare il bit
+\acr{suid} il valore da fornire sarebbe $4755$.
\begin{table}[!htb]
\centering
particolare:
\begin{enumerate}
\item siccome solo l'amministratore può impostare lo \textit{sticky bit}, se
- l'\textit{effective user id} del processo non è zero esso viene
- automaticamente cancellato (senza notifica di errore) qualora sia stato
- indicato in \var{mode}.
+ l'userid effettivo del processo non è zero esso viene automaticamente
+ cancellato (senza notifica di errore) qualora sia stato indicato in
+ \var{mode}.
\item per via della semantica SVr4 nella creazione dei nuovi file, si può
avere il caso in cui il file creato da un processo è assegnato a un gruppo
per il quale il processo non ha privilegi. Per evitare che si possa
- assegnare il bit \acr{sgid} ad un file appartenente a un gruppo per cui
- non si hanno diritti, questo viene automaticamente cancellato (senza
- notifica di errore) da \var{mode} qualora il gruppo del file non corrisponda
- a quelli associati al processo (la cosa non avviene quando
- l'\textit{effective user id} del processo è zero).
+ assegnare il bit \acr{sgid} ad un file appartenente a un gruppo per cui non
+ si hanno diritti, questo viene automaticamente cancellato (senza notifica di
+ errore) da \var{mode} qualora il gruppo del file non corrisponda a quelli
+ associati al processo (la cosa non avviene quando l'userid effettivo del
+ processo è zero).
\end{enumerate}
Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
specificati dalle variabili \var{owner} e \var{group}.
\bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
- un errore, in caso di errore \var{errno} viene impostata ai valori:
+ un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
- \item[\macro{EPERM}] L'\textit{effective user id} non corrisponde a quello
- del proprietario del file o non è zero, o utente e gruppo non sono validi
+ \item[\macro{EPERM}] L'userid 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 \macro{EROFS} e
\macro{EIO}; \func{chown} restituisce anche \macro{EFAULT},
\param{path}.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per
- un errore, in caso di errore \var{errno} viene impostata ai valori:
+ un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
- \item[\macro{EPERM}] L'\textit{effective user id} non è zero.
+ \item[\macro{EPERM}] L'userid effettivo del processo non è zero.
\end{errlist}
ed inoltre \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT},
\macro{ENOMEM}, \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP};
projects / gapil.git / blobdiff