%% filedir.tex
%%
-%% Copyright (C) 2000-2008 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2009 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
La struttura \struct{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 fig.~\ref{fig:file_stat_struct}, così come
-riportata dalla pagina di manuale di \func{stat} (in realtà la definizione
+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).
+riservati per estensioni come tempi dei file più precisi (vedi
+sez.~\ref{sec:file_file_times}), o per il padding dei campi.
\begin{figure}[!htb]
\footnotesize
primitivi del sistema (di quelli definiti in
tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
-% TODO: aggiornare con i cambiamenti ai tempi fatti con il 2.6
-
\subsection{I tipi di file}
\label{sec:file_types}
il filesystem, ma ovviamente in questo modo la cosa è molto più complicata da
realizzare.
+Infine a partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei
+campi di tab.~\ref{tab:file_file_times} è espressa in secondi, è stata
+portata ai nanosecondi per la gran parte dei filesystem. La ulteriore
+informazione può essere acceduta attraverso altri campi; se si sono definite
+le macro \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE} questi sono
+\var{st\_atim.tv\_nsec}, \var{st\_mtim.tv\_nsec} e \var{st\_ctim.tv\_nsec} se
+queste non sono definite, \var{st\_atimensec}, \var{st\_mtimensec} e
+\var{st\_mtimensec}. Qualora il supporto per questa maggior precisione sia
+assente questi campi aggiuntivi saranno nulli.
+
+%TODO documentare utimes
\section{Il controllo di accesso ai file}
l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se
l'utente originale ha i permessi per accedere ad un certo file.
-% TODO documentare euidaccess (e eaccess)
+Del tutto analoghe a \func{access} sono le due funzioni \funcd{euidaccess} e
+\funcd{eaccess} che ripetono lo stesso controllo usando però gli
+identificatori del gruppo effettivo, verificando quindi le effettive capacità
+di accesso ad un file. Le funzioni hanno entrambe lo stesso
+prototipo\footnote{in realtà \func{eaccess} è solo un sinonimo di
+ \func{euidaccess} fornita per compatibilità con l'uso di questo nome in
+ altri sistemi.} che è del tutto identico a quello di \func{access}. Prendono
+anche gli stessi valori e restituiscono gli stessi risultati e gli stessi
+codici di errore.
Per cambiare i permessi di un file il sistema mette ad disposizione due
funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}{|c|p{10cm}|}
+ \begin{tabular}{|l|p{10cm}|}
\hline
\textbf{Nome} & \textbf{Descrizione} \\
\hline
Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
-impiega per realizzare delle estensioni (come le ACL, \index{SELinux} SELinux,
-ecc.) al tradizionale meccanismo dei controlli di accesso di Unix, l'accesso
-ai loro valori viene regolato in maniera diversa a seconda sia della loro
-classe sia di quali, fra le estensioni che li utilizzano, sono poste in uso.
-In particolare, per ciascuna delle classi riportate in
-tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi:
-\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
+ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
+di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
+a seconda sia della loro classe sia di quali, fra le estensioni che li
+utilizzano, sono poste in uso. In particolare, per ciascuna delle classi
+riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
+casi:
+\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
dipende dalle politiche di sicurezza stabilite da loro stessi tramite
l'utilizzo di un sistema di controllo basato sui
\item[\texttt{system}] Anche l'accesso agli \textit{extended system
attributes} dipende dalle politiche di accesso che il kernel realizza
anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
- delle ACL l'accesso è consentito in lettura ai processi che hanno la
- capacità di eseguire una ricerca sul file (cioè hanno il permesso di lettura
- sulla directory che contiene il file) ed in scrittura al proprietario del
- file o ai processi dotati della \textit{capability} \index{capabilities}
- \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a
- quella impiegata per gli ordinari permessi dei file.}
+ delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
+ processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
+ il permesso di lettura sulla directory che contiene il file) ed in scrittura
+ al proprietario del file o ai processi dotati della \textit{capability}
+ \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica
+ di accesso analoga a quella impiegata per gli ordinari permessi dei file.}
\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
per la lettura che per la scrittura, è consentito soltanto ai processi con
controllo che accedono ad informazioni non disponibili ai processi ordinari.
\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
- regolato dagli ordinari permessi dei file a cui essi fanno riferimento:
- occorre avere il permesso di lettura per leggerli e quello di scrittura per
- scriverli o modificarli. Dato l'uso di questi attributi, si è scelto cioè di
- applicare per il loro accesso gli stessi criteri che si usano per l'accesso
- al contenuto dei file (o delle directory) cui essi fanno riferimento.
-
- Questa scelta vale però soltanto per i file e le directory ordinarie, se
- valesse in generale infatti si avrebbe un serio problema di sicurezza dato
- che esistono diversi oggetti sul filesystem per i quali è normale avere
- avere il permesso di scrittura consentito a tutti gli utenti, come i link
- simbolici, o alcuni file di dispositivo come \texttt{/dev/null}. Se fosse
- possibile usare su di essi gli \textit{extended user attributes} un utente
- qualunque potrebbe inserirvi dati a piacere.\footnote{la cosa è stata notata
- su XFS, dove questo comportamento permetteva, non essendovi limiti sullo
- spazio occupabile dagli \textit{Extended Attributes}, di bloccare il
- sistema riempiendo il disco.}
-
- La semantica del controllo di accesso che abbiamo indicato inoltre non
- avrebbe alcun senso al di fuori di file e directory: i permessi di lettura e
- scrittura per un file di dispositivo attengono alle capacità di accesso al
- dispositivo sottostante,\footnote{motivo per cui si può formattare un disco
- anche se \texttt{/dev} è su un filesystem in sola lettura.} mentre per i
- link simbolici questi vengono semplicemente ignorati: in nessuno dei due
- casi hanno a che fare con il contenuto del file, e nella discussione
- relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
- capace di indicare una qualche forma sensata di utilizzo degli stessi per
- link simbolici o file di dispositivo, e neanche per le fifo o i socket.
-
- Per questo motivo gli \textit{extended user attributes} sono stati
- completamente disabilitati per tutto ciò che non sia un file regolare o una
- directory.\footnote{si può verificare la semantica adottata consultando il
- file \texttt{fs/xattr.c} dei sorgenti del kernel.} Inoltre per le
- directory è stata introdotta una ulteriore restrizione, dovuta di nuovo alla
- presenza ordinaria di permessi di scrittura completi su directory come
- \texttt{/tmp}. Questo è un altro caso particolare, in cui il premesso di
- scrittura viene usato, unito alla presenza dello \itindex{sticky~bit}
- \textit{sticky bit}, per garantire il permesso di creazione di nuovi file.
- Per questo motivo, per evitare eventuali abusi, se una directory ha lo
- \itindex{sticky~bit} \textit{sticky bit} attivo sarà consentito scrivere i
- suoi \textit{extended user attributes} soltanto se si è proprietari della
- stessa, o si hanno i privilegi amministrativi della capability
- \index{capabilities} \const{CAP\_FOWNER}.
+ regolato dai normali permessi dei file: occorre avere il permesso di lettura
+ per leggerli e quello di scrittura per scriverli o modificarli. Dato l'uso
+ di questi attributi si è scelto di applicare al loro accesso gli stessi
+ criteri che si usano per l'accesso al contenuto dei file (o delle directory)
+ cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
+ directory ordinarie, se valesse in generale infatti si avrebbe un serio
+ problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
+ quali è normale avere avere il permesso di scrittura consentito a tutti gli
+ utenti, come i link simbolici, o alcuni file di dispositivo come
+ \texttt{/dev/null}. Se fosse possibile usare su di essi gli \textit{extended
+ user attributes} un utente qualunque potrebbe inserirvi dati a
+ piacere.\footnote{la cosa è stata notata su XFS, dove questo comportamento
+ permetteva, non essendovi limiti sullo spazio occupabile dagli
+ \textit{Extended Attributes}, di bloccare il sistema riempiendo il disco.}
+
+ La semantica del controllo di accesso indicata inoltre non avrebbe alcun
+ senso al di fuori di file e directory: i permessi di lettura e scrittura per
+ un file di dispositivo attengono alle capacità di accesso al dispositivo
+ sottostante,\footnote{motivo per cui si può formattare un disco anche se
+ \texttt{/dev} è su un filesystem in sola lettura.} mentre per i link
+ simbolici questi vengono semplicemente ignorati: in nessuno dei due casi
+ hanno a che fare con il contenuto del file, e nella discussione relativa
+ all'uso degli \textit{extended user attributes} nessuno è mai stato capace
+ di indicare una qualche forma sensata di utilizzo degli stessi per link
+ simbolici o file di dispositivo, e neanche per le fifo o i socket. Per
+ questo motivo essi sono stati completamente disabilitati per tutto ciò che
+ non sia un file regolare o una directory.\footnote{si può verificare la
+ semantica adottata consultando il file \texttt{fs/xattr.c} dei sorgenti
+ del kernel.} Inoltre per le directory è stata introdotta una ulteriore
+ restrizione, dovuta di nuovo alla presenza ordinaria di permessi di
+ scrittura completi su directory come \texttt{/tmp}. Per questo motivo, per
+ evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
+ \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
+ user attributes} soltanto se si è proprietari della stessa, o si hanno i
+ privilegi amministrativi della capability \index{capabilities}
+ \const{CAP\_FOWNER}.
\end{basedescript}
Le funzioni per la gestione degli attributi estesi, come altre funzioni di
gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
installata a parte;\footnote{la versione corrente della libreria è
- \texttt{libattr1}, e nel caso si usi Debian la si può installare con il
- pacchetto omonimo ed il collegato \texttt{libattr1-dev}.} pertanto se un
-programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
-libreria invocando il compilatore con l'opzione \texttt{-lattr}.
+ \texttt{libattr1}.} pertanto se un programma le utilizza si dovrà indicare
+esplicitamente l'uso della suddetta libreria invocando il compilatore con
+l'opzione \texttt{-lattr}.
Per poter leggere gli attributi estesi sono disponibili tre diverse funzioni,
\funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che consentono
\item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
filesystem o sono disabilitati.
\end{errlist}
- Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
- ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
- all'attributo. }
+ e tutti gli errori di \func{stat}, come \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo. }
\end{functions}
Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
\itindend{Extended~Attributes}
-% TODO trattare gli attributi estesi e le funzioni la documentazione di
-% sistema è nei pacchetti libxattr1-dev e attr
-
-
\subsection{Le \textit{Access Control List}}
\label{sec:file_ACL}
questa funzione è una estensione specifica di Linux, e non è presente nella
bozza dello standard POSIX.1e.
+Per quanto utile per la visualizzazione o l'impostazione da comando delle ACL,
+la forma testuale non è la più efficiente per poter memorizzare i dati
+relativi ad una ACL, ad esempio quando si vuole eseguirne una copia a scopo di
+archiviazione. Per questo è stata prevista la possibilità di utilizzare una
+rappresentazione delle ACL in una apposita forma binaria contigua e
+persistente. È così possibile copiare il valore di una ACL in un buffer e da
+questa rappresentazione tornare indietro e generare una ACL.
+
+Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
+semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
+la citata rappresentazione binaria, in modo da poter allocare per essa un
+buffer di dimensione sufficiente, il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{ssize\_t acl\_size(acl\_t acl)}
-\itindend{Access~Control~List}
+ Determina la dimensione della rappresentazione binaria di una ACL.
+
+ \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
+ della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \end{errlist}
+
+}
+\end{functions}
+Prima di effettuare la lettura della rappresentazione binaria è sempre
+necessario allocare un buffer di dimensione sufficiente a contenerla, pertanto
+prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
+poi allocare il buffer con una delle funzioni di
+sez.~\ref{sec:proc_mem_alloc}. Una volta terminato l'uso della
+rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
+
+La funzione che consente di leggere la rappresentazione binaria di una ACL è
+\funcd{acl\_copy\_ext}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{ssize\_t acl\_copy\_ext(void *buf\_p, acl\_t acl, ssize\_t size)}
+
+ Ottiene la rappresentazione binaria di una ACL.
+
+ \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
+ della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
+ \param{size} è negativo o nullo.
+ \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
+ dimensione della rappresentazione della ACL.
+ \end{errlist}
+
+}
+\end{functions}
+
+La funzione salverà la rappresentazione binaria della ACL indicata da
+\param{acl} sul buffer posto all'indirizzo \param{buf\_p} e lungo \param{size}
+byte, restituendo la dimensione della stessa come valore di ritorno. Qualora
+la dimensione della rappresentazione ecceda il valore di \param{size} la
+funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
+effetto sulla ACL indicata da \param{acl}.
+
+Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione
+binaria della stessa disponibile in un buffer si potrà usare la funzione
+\funcd{acl\_copy\_int}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{ssize\_t acl\_copy\_int(const void *buf\_p)}
+
+ Ripristina la rappresentazione binaria di una ACL.
+
+ \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+ di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+ \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] il buffer all'indirizzo \param{buf\_p} non contiene
+ una rappresentazione corretta di una ACL.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
+ \type{acl\_t} per la ACL richiesta.
+ \end{errlist}
+
+}
+\end{functions}
+
+La funzione in caso di successo alloca autonomamente un oggetto di tipo
+\type{acl\_t} che viene restituito come valore di ritorno con il contenuto
+della ACL rappresentata dai dati contenuti nel buffer puntato da
+\param{buf\_p}. Si ricordi che come per le precedenti funzioni l'oggetto
+\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
+utilizzo.
+
+Una volta che si disponga della ACL desiderata, questa potrà essere impostata
+su un file o una directory. Per impostare una ACL sono disponibili due
+funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
+directory, ed il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t
+ acl)}
+
+ Imposta una ACL su un file o una directory.
+
+ \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[\errcode{EACCES}] o un generico errore di accesso a \param{path} o il
+ valore di \param{type} specifica una ACL il cui tipo non può essere
+ assegnato a \param{path}.
+ \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+ ha in valore non corretto.
+ \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+ dati aggiuntivi della ACL.
+ \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+ contenuto in un filesystem che non supporta le ACL.
+ \end{errlist}
+ ed inoltre \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
+ \errval{EROFS}, \errval{EPERM}.
+}
+\end{functions}
+
+La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
+alla directory indicate dal pathname \param{path}, mentre con \param{type} si
+indica il tipo di ACL utilizzando le constanti di tab.~\ref{tab:acl_type}, ma
+si tenga presente che le ACL di default possono essere solo impostate
+qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
+successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
+unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
+ACL di default associata a \func{path}.\footnote{questo però è una estensione
+ della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
+ prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
+ prende come unico argomento il pathname della directory di cui si vuole
+ cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
+ manuale.} La seconda funzione che consente di impostare una ACL è
+\funcd{acl\_set\_fd}, ed il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{int acl\_set\_fd(int fd, acl\_t acl)}
+
+ Imposta una ACL su un file descriptor.
+
+ \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[\errcode{EBADF}].
+ \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+ ha in valore non corretto.
+ \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+ dati aggiuntivi della ACL.
+ \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+ contenuto in un filesystem che non supporta le ACL.
+ \end{errlist}
+ ed inoltre \errval{EBADF}, \errval{EROFS}, \errval{EPERM}.
+}
+\end{functions}
+
+La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+esclusivamente sui file identificati tramite un file descriptor. Non dovendo
+avere a che fare con directory (e con la conseguente possibilità di avere una
+ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
+che sarà sempre di accesso, e prende come unico argomento, a parte il file
+descriptor, la ACL da impostare.
+
+Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
+sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In
+generale è possibile modificare un singolo valore all'interno di una singola
+voce direttamente con le funzioni previste dallo standard POSIX.1e. Queste
+funzioni però sono alquanto macchinose da utilizzare per cui è molto più
+semplice operare direttamente sulla rappresentazione testuale. Questo è il
+motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
+descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
+manuale.
+
+Se si vuole operare direttamente sui contenuti di un oggetto di tipo
+\type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli
+opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
+dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla
+funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della
+prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
+singole voci successive alla prima.
+
+Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
+voci; con le funzioni \funcd{acl\_get\_tag\_type}, \funcd{acl\_get\_qualifier},
+\funcd{acl\_get\_permset} si potranno leggere rispettivamente tipo,
+qualificatore e permessi mentre con le corrispondente funzioni
+\funcd{acl\_set\_tag\_type}, \funcd{acl\_set\_qualifier},
+\funcd{acl\_set\_permset} si possono impostare i valori; in entrambi i casi
+vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole
+ pagine di manuale.} Si possono poi copiare i valori di una voce da una ACL
+ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
+\funcd{acl\_delete\_entry}.
+
+\itindend{Access~Control~List}
-% TODO trattare le ACL, la documentazione di sistema è nei pacchetti
-% libacl1-dev e acl
+% la documentazione di sistema è nei pacchetti libacl1-dev e acl
% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by
% LocalWords: removexattr lremovexattr fremovexattr attributename lacl acl
% LocalWords: OBJ setfacl len any prefix separator options NUMERIC IDS SMART
-% LocalWords: INDENT major number IDE Documentation makedev fopendir proc
+% LocalWords: INDENT major number IDE Documentation makedev fopendir proc copy
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: euidaccess eaccess delete def tag qualifier permset