\subsection{I permessi per l'accesso ai file}
\label{sec:file_perm_overview}
-Il controllo di accesso ai file in unix segue un modello abbastanza semplice,
-ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre
-livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
-tipo unix, e non è detto che sia applicabile a un filesystem
+Il controllo di accesso ai file in unix segue un modello abbastanza semplice
+(ma adatto alla gran parte delle esigenze) in cui si dividono i permessi su
+tre livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem
+di tipo unix, e non è detto che sia applicabile a un filesystem
qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
per il quale i permessi vengono assegnati in maniera fissa con un opzione in
fase di montaggio}. Esistono inoltre estensioni che permettono di
Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
-identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}). Questi valori
+identificatori di utenti e gruppi (\acr{uid} e \acr{gid}). Questi valori
sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
della struttura \var{stat} (si veda \secref{sec:file_stat}). Ad ogni file
viene inoltre associato un insieme di permessi che sono divisi in tre classi,
usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
esecuzione (indicati nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e
\cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti
-gli altri. I restanti tre bit (\textsl{suid}, \textsl{sgid}, e
+gli altri. I restanti tre bit (\acr{suid}, \acr{sgid}, e
\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e
\secref{sec:file_sticky}).
Non si può creare un file fintanto che non si disponga del permesso di
esecuzione e di quello di scrittura per la directory di destinazione; gli
stessi permessi occorrono per cancellare un file da una directory (si ricordi
-che questo non implica necessariamente la rimozione fisica del file), non è
-necessario nessun tipo di permesso per il file stesso (infatti esso non viene
-toccato, viene solo modificato il contenuto della directory, rimuovendo la
-voce che ad esso fa rifermento).
+che questo non implica necessariamente la rimozione del contenuto del file dal
+disco), non è necessario nessun tipo di permesso per il file stesso (infatti
+esso non viene toccato, viene solo modificato il contenuto della directory,
+rimuovendo la voce che ad esso fa rifermento).
Per poter eseguire un file (che sia un programma compilato od uno script di
-shell), occorre il permesso di esecuzione per il medesimo, inoltre solo i file
-regolari possono essere eseguiti.
+shell, od un altro tipo di file eseguibile riconosciuto dal kernel), occorre
+avere il permesso di esecuzione, inoltre solo i file regolari possono essere
+eseguiti.
I permessi per un link simbolico sono ignorati, contano quelli del file a cui
fa riferimento; per questo in genere \cmd{ls} per un link simbolico riporta
del processo.
Per una spiegazione dettagliata degli identificatori associati ai processi si
-veda \secref{sec:prochand_perms}; normalmente, a parte quanto vedremo in
+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 uid e gid dell'utente che ha
-lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei
-gruppi cui l'utente appartiene.
-
-% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
-% confrontandoli con quelli del file e se l'operazione richiesta è compatibile
-% con i permessi associati al file essa viene eseguita, altrimenti viene
-% bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
-% viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale
-% a
-% pertanto accesso senza restrizione a qualunque file del sistema.
-
-% In realtà il procedimento è più complesso di quanto descritto in maniera
-% elementare qui; inoltre ad un processo sono associati diversi identificatori,
-% torneremo su questo in maggiori dettagli in seguito in
-% \secref{sec:proc_perms}.
+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.
I passi attraverso i quali viene stabilito se il processo possiede il diritto
di accesso sono i seguenti:
\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 gid del file
- allora:
+ \textit{supplementary group id} dei processi corrispondono al \acr{gid} del
+ file allora:
\begin{itemize}
\item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
consentito,
\item altrimenti l'accesso è negato
\end{itemize}
\item se il bit dei permessi d'accesso per tutti gli altri è settato,
- l'accesso è consentito, altrimenti l'accesso è negato.
+ l'accesso è consentito, altrimenti l'accesso è negato.
\end{itemize}
Si tenga presente che questi passi vengono eseguiti esattamente in
tutti gli altri non vengono controllati.
-\subsection{I bit \textsl{suid} e \textsl{sgid}}
+\subsection{I bit \acr{suid} e \acr{sgid}}
\label{sec:file_suid_sgid}
Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del
campo \var{st\_mode} usati per il controllo di accesso oltre ai bit dei
permessi veri e propri, ci sono altri tre bit che vengono usati per indicare
alcune proprietà speciali dei file. Due di questi sono i bit detti
-\textsl{suid} (o \textit{set-user-ID bit}) e \textsl{sgid} (o
+\acr{suid} (o \textit{set-user-ID bit}) e \acr{sgid} (o
\textit{set-group-ID bit}) che sono identificati dalle constanti
\macro{S\_ISUID} e \macro{S\_ISGID}.
-Come spiegato in dettaglio in \secref{sec:prochand_exec}, quando si lancia un
+Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
programma il comportamendo normale del kernel è quello di settare
l'\textit{effective user id} e l'\textit{effective group id} del nuovo
-processo all'uid e al gid del processo corrente, che normalmente corrispondono
-dell'utente con cui si è entrati nel sistema.
+processo all'\acr{uid} e al \acr{gid} del processo corrente, che normalmente
+corrispondono dell'utente con cui si è entrati nel sistema.
-Se però il file del programma (che ovviamente deve essere eseguibile) ha il
-bit \textsl{suid} settato, il kernel assegnerà come \textit{effective user id}
-al nuovo processo l'uid del proprietario del file al posto dell'uid del
-processo originario. Avere il bit \textsl{sgid} settato ha lo stesso effetto
-sull'\textit{effective group id} del processo.
+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} settato, il kernel
+assegnerà come \textit{effective user id} al nuovo processo l'uid del
+proprietario del file al posto dell'uid del processo originario. Avere il bit
+\acr{sgid} settato ha lo stesso effetto sull'\textit{effective group id} del
+processo.
I bit \textsl{suid} e \textsl{sgid} vengono usati per permettere agli utenti
normali di usare programmi che abbisognano di privilegi speciali; l'esempio
classico è il comando \cmd{passwd} che ha la necessità di modificare il file
delle password, quest'ultimo ovviamente può essere scritto solo
dall'amministratore, ma non è necessario chiamare l'amministratore per
-cambiare la propria password. Infatti il comando \cmd{passwd} appartiene a root
-ma ha il suid bit settato per cui quando viene lanciato da un utente normale
-parte con i privilegi di root.
+cambiare la propria password. Infatti il comando \cmd{passwd} appartiene a
+root ma ha il bit suid settato per cui quando viene lanciato da un utente
+normale parte con i privilegi di root.
Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
-programmi devono essere scritti accuratamente (torneremo sull'argomento in
-\secref{sec:prochand_perms}) per evitare che possano essere usati per
-guadagnare privilegi non consentiti.
+programmi devono essere scritti accuratamente per evitare che possano essere
+usati per guadagnare privilegi non consentiti (torneremo sull'argomento in
+\secref{sec:proc_perms}).
-La presenza dei bit \textsl{suid} e \textsl{sgid} su un file può essere
+La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere
rilevata con il comando \cmd{ls -l}, in tal caso comparirà la lettera \cmd{s}
al posto della \cmd{x} in corrispondenza dei permessi di utente o gruppo. La
stessa lettera \cmd{s} può essere usata nel comando \cmd{chmod} per settare
veda \secref{sec:file_ownership} per una spiegazione dettagliata al
proposito).
-Infine Linux utilizza il bit \textsl{sgid} per una ulteriore estensione
-mutuata da SVR4. Il caso in cui il file abbia il bit \textsl{sgid} settato ma
+Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione
+mutuata da SVR4. Il caso in cui il file abbia il bit \acr{sgid} settato ma
non il corrispondente bit di esecuzione viene utilizzato per attivare per
quel file il \textit{mandatory locking} (argomento che affronteremo nei
dettagli in \secref{sec:xxx_mandatory_lock}).
prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della
mecchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file
continuo indicizzato direttamente in questo modo si poteva risparmiare in
-tempo di caricamento rispetto alla ricerca del file su disco.
+tempo di caricamento rispetto alla ricerca del file su disco. Lo
+\textsl{sticky bit} è indicato usando la lettera \cmd{t} al posto della
+\cmd{x} nei permessi per gli altri.
Ovviamente per evitare che gli utenti potessero intasare la swap solo
l'amministratore era in grado di settare questo bit, che venne chiamato anche
-\textit{saved text bit}, da cui deriva il nome della costante. Le attuali
-implementazioni di memoria virtuale e filesystem rendono sostanzialmente
-inutile questo procedimento. Lo \textsl{sticky bit} è indicato attraverso la
-lettera \cmd{t} al posto della \cmd{x} nei permessi per gli altri.
+con il nome di \textit{saved text bit}, da cui deriva quello della costante.
+Le attuali implementazioni di memoria virtuale e filesystem rendono
+sostanzialmente inutile questo procedimento.
Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
-assunto un uso corrente per le directory\footnote{lo \textsl{sticky bit} è una
- estensione non definita nello standard POSIX, Linux però la supporta, così
- come BSD e SVR4}, in questo caso se il bit è settato un file potrà essere
-rimosso dalla directory soltanto se l'utente ha il permesso di scrittura ed
-inoltre è vera una delle seguenti condizioni:
+assunto un uso corrente per le directory\footnote{lo \textsl{sticky bit} per
+ le directory è una estensione non definita nello standard POSIX, Linux però
+ la supporta, così come BSD e SVR4}, in questo caso se il bit è settato un
+file potrà essere rimosso dalla directory soltanto se l'utente ha il permesso
+di scrittura ed inoltre è vera una delle seguenti condizioni:
\begin{itemize}
\item l'utente è proprietario del file
\item l'utente è proprietario della directory
un classico esempio di directory che ha questo bit settato è \file{/tmp}, i
permessi infatti di solito sono settati come:
\begin{verbatim}
-$ ls -l /tmp
+$ ls -ld /tmp
drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
\end{verbatim}%$
in questo modo chiunque può leggere, scrivere ed eseguire i file temporanei
ivi memorizzati, sia crearne di nuovi, ma solo l'utente che ha creato un file
-nella directory potrà cancellarlo o rinominarlo, evitando così che utente
-possa, più o meno consapevolemnte, cancellare i file degli altri.
+nella directory potrà cancellarlo o rinominarlo, così si può evitare che un
+utente possa, più o meno consapevolemnte, cancellare i file degli altri.
\subsection{La titolarità di nuovi file e directory}
descritto in \secref{sec:file_dir_creat_rem}).
Lo standard POSIX prescrive che l'uid del nuovo file corrisponda
-all'\textit{effective user id} del processo che lo crea; per il gid invece
-prevede due diverse possibilità:
+all'\textit{effective user id} del processo che lo crea; per il \acr{gid}
+invece prevede due diverse possibilità:
\begin{itemize}
-\item il gid del file corrisponde all'\textit{effective group id} del processo.
-\item il gid del file corrisponde al gid della directory in cui esso è creato.
+\item il \acr{gid} del file corrisponde all'\textit{effective group id} del
+ processo.
+\item il \acr{gid} del file corrisponde al 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 gid
-del processo, se però la directory in cui viene creato il file ha il bit
-\textsl{sgid} settato allora viene usata la seconda opzione..
+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
+bit \acr{sgid} settato allora viene usata la seconda opzione..
-Usare la semantica BSD ha il vantaggio che il gid viene sempre automaticamente
-propagato, restando coerente a quello della directory di partenza, in tutte le
-sottodirectory. La semantica SVR4 offre una maggiore possibilità di scelta, ma
-per ottenere lo stesso risultato necessita che per le nuove directory venga
-anche propagato anche il bit sgid. Questo è comunque il comportamento di
-default di \func{mkdir}, ed é in questo modo ad esempio che Debian assicura
-che le sottodirectory create nelle home di un utente restino sempre con il gid
-del gruppo primario dello stesso.
+Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+automaticamente propagato, restando coerente a quello della directory di
+partenza, in tutte le sottodirectory. La semantica SVR4 offre una maggiore
+possibilità di scelta, ma per ottenere lo stesso risultato necessita che per
+le nuove directory venga anche propagato anche il bit \acr{sgid}. Questo è
+comunque il comportamento di default di \func{mkdir}, ed é in questo modo ad
+esempio che Debian assicura che le sottodirectory create nelle home di un
+utente restino sempre con il \acr{gid} del gruppo primario dello stesso.
\subsection{La funzione \texttt{access}}
group id} del processo, ma ci sono casi in cui si può voler effettuare il
controllo usando il \textit{real user id} e il \textit{real group id} (cioè
l'uid dell'utente che ha lanciato il programma, che, come accennato in
-\secref{sec:file_suid_sgid} e spiegato in \secref{sec:prochand_perms} non è
+\secref{sec:file_suid_sgid} e spiegato in \secref{sec:proc_perms} non è
detto sia uguale all'\textit{effective user id}). Per far questo si può usare
la funzione \func{access}, il cui prototipo è:
\funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa
il file descriptor \var{fd} per indicare il file.
-
+
Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
- caso di errore \texttt{errno} viene settato ai valori:
+ caso di errore \texttt{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.
\end{errlist}
- Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
- \macro{EIO}; \func{chmod} restituisce anche \macro{EFAULT},
- \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
- \macro{EACCES}, \macro{ELOOP}; \func{fchmod} anche \macro{EBADF}.
+ ed inoltre \macro{EROFS} e \macro{EIO}; \func{chmod} restituisce anche
+ \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM},
+ \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP}; \func{fchmod} anche
+ \macro{EBADF}.
\end{functions}
I valori possibili per \var{mode} sono indicati in \ntab. I valori possono
\hline
\hline
\macro{S\_ISUID} & 04000 & set user ID \\
-
\macro{S\_ISGID} & 02000 & set group ID \\
-
\macro{S\_ISVTX} & 01000 & sticky bit \\
-
\hline
\macro{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\
-
\macro{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura \\
-
\macro{S\_IWUSR} & 00200 & l'utente ha il permesso di scrittura \\
-
\macro{S\_IXUSR} & 00100 & l'utente ha il permesso di esecuzione \\
-
\hline
\macro{S\_IRWXG} & 00070 & il gruppo ha tutti i permessi \\
-
\macro{S\_IRGRP} & 00040 & il gruppo ha il permesso di lettura \\
-
\macro{S\_IWGRP} & 00020 & il gruppo ha il permesso di scrittura \\
-
\macro{S\_IXGRP} & 00010 & il gruppo ha il permesso di esecuzione \\
-
\hline
\macro{S\_IRWXO} & 00007 & gli altri hanno tutti i permessi \\
-
\macro{S\_IROTH} & 00004 & gli altri hanno il permesso di lettura \\
-
\macro{S\_IWOTH} & 00002 & gli altri hanno il permesso di scrittura \\
-
\macro{S\_IXOTH} & 00001 & gli altri hanno il permesso di esecuzione \\
-
\hline
\end{tabular}
\caption{I valori delle costanti usate per indicare i permessi dei file.}
\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 \textsl{sgid} ad un file appartenente a un gruppo per cui
+ 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
Per alcuni filesystem\footnote{il filesystem \textsl{ext2} supporta questa
caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
-misura di sicurezza, volta ad scongiurare l'abuso dei bit \textsl{suid} e
-\textsl{sgid}; essa consiste nel cancellare automaticamente questi bit qualora
-un processo che non appartenga all'amministratore scriva su un file. In questo
-modo anche se un utente malizioso scopre un file \textsl{suid} su cui può
+misura di sicurezza, volta ad scongiurare l'abuso dei bit \acr{suid} e
+\acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un
+processo che non appartenga all'amministratore scriva su un file. In questo
+modo anche se un utente malizioso scopre un file \acr{suid} su cui può
scrivere, un eventuale modifica comporterà la perdita di ogni ulteriore
privilegio.
esplicitamente.
In genere il valore di \func{umask} viene stabilito una volta per tutte al
-login, e di norma gli utenti non hanno motivi per modificarlo. Se però si
-vuole che un processo possa creare un file che chiunque possa leggere allora
-occorrerà cambiare il valore di \func{umask}.
+login a $022$, e di norma gli utenti non hanno motivi per modificarlo. Se però
+si vuole che un processo possa creare un file che chiunque possa leggere
+allora occorrerà cambiare il valore di \func{umask}.
\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
\label{sec:file_chown}
\macro{EACCES}, \macro{ELOOP}; \func{fchown} anche \macro{EBADF}.
\end{functions}
-Soltanto l'amministratore può cambiare il proprietario di un file, seguendo la
-semantica di BSD che non consente agli utenti di assegnare i loro file ad
-altri (per evitare eventuali aggiramenti delle quote). L'amministratore può
-cambiare il gruppo di un file, il proprietario può cambiare il gruppo dei file
-che gli appartengono solo se il nuovo gruppo è il suo gruppo primario o uno
-dei gruppi a cui appartiene.
+In Linux soltanto l'amministratore può cambiare il proprietario di un file,
+seguendo la semantica di BSD che non consente agli utenti di assegnare i loro
+file ad altri (per evitare eventuali aggiramenti delle quote).
+L'amministratore può cambiare il gruppo di un file, il proprietario può
+cambiare il gruppo dei file che gli appartengono solo se il nuovo gruppo è il
+suo gruppo primario o uno dei gruppi a cui appartiene.
La funzione \func{chown} segue i link simbolici, per operare direttamente su
in link simbolico si deve usare la funzione \func{lchown}\footnote{fino alla
valore per \var{owner} e \var{group} i valori restano immutati.
Quando queste funzioni sono chiamate con successo da un processo senza i
-privilegi di root entrambi i bit \textsl{suid} e \textsl{sgid} vengono
-cancellati. Questo non avviene per il bit \textsl{sgid} nel caso in cui esso
+privilegi di root entrambi i bit \acr{suid} e \acr{sgid} vengono
+cancellati. Questo non avviene per il bit \acr{sgid} nel caso in cui esso
sia usato (in assenza del corrispondente permesso di esecuzione) per indicare
che per il file è attivo il \textit{mandatory locking}.
informazioni relative al controllo di accesso, sono mantenute nell'inode.
Vedremo in questa sezione come sia possibile leggere tutte queste informazioni
-usando la funzione \texttt{stat}, esamineremo poi le varie funzioni che si
-possono per manipolare le restanti informazioni (avendo esaminato quelle per
-la gestione del controllo di accesso in \secref{sec:file_access_control}).
+usando la funzione \texttt{stat}, che permette l'accesso a tutti i dati
+memorizzati nell'inode; esamineremo poi le varie funzioni usate per manipolare
+tutte queste informazioni (eccetto quelle che riguardano la gestione del
+controllo di accesso, già trattate in in \secref{sec:file_access_control}).
\subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
\label{sec:file_stat}
La lettura delle informazioni relative ai file è fatta attraverso la famiglia
-delle funzioni \func{stat}, che è la funzione che il comando \cmd{ls} usa
-per poter stampare tutti i dati dei files. I prototipi di queste funzioni sono
-i seguenti:
+delle funzioni \func{stat}; questa è la funzione che il comando \cmd{ls} usa
+per poter ottenere e mostrare tutti i dati dei files. I prototipi di queste
+funzioni sono i seguenti:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
descriptor \var{filedes}.
Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
- caso di errore \texttt{errno} viene settato ai valori \macro{EACCESS},
- \macro{EBADF}, \macro{ELOOP}, \macro{EFAULT}, \macro{ENOENT},
- \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ENAMETOOLONG}.
+ caso di errore \texttt{errno} può assumere uno dei valori: \macro{EBADF},
+ \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP}, \macro{EFAULT},
+ \macro{EACCESS}, \macro{ENOMEM}, \macro{ENAMETOOLONG}.
\end{functions}
La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in
standard POSIX definisce un insieme di macro per verificare il tipo di files,
queste vengono usate anche da Linux che supporta pure le estensioni per link
simbolici e socket definite da BSD, l'elenco completo di tutte le macro
-definite in GNU/Linux è riportato in \ntab:
+definite in GNU/Linux è riportato in \ntab.
\begin{table}[htb]
\centering
\footnotesize
anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
nella nostra directory con un link del tipo:
\begin{verbatim}
-$ln -s /tmp/tmp_file temporaneo
+$ ln -s /tmp/tmp_file temporaneo
\end{verbatim}%$
ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura
\file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola
parlavamo in \secref{sec:file_vfs}) in una opportuna struttura
\texttt{struct dirent}.
+(NdA Il resto va scritto!!! É noioso e lo farò più avanti).
+
+
\subsection{La directory di lavoro}
\label{sec:file_work_dir}
fatta per compatibilità all'indietro con BSD, che non consente di specificare
la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
-\secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
+\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
contenere il nome del file, e questa è la ragione principale per cui questa
funzione è deprecata.
projects / gapil.git / blobdiff