25 accessed. These Bits are sometimes called the \emph{permission |
25 accessed. These Bits are sometimes called the \emph{permission |
26 attributes} of a file. There are typically three modes for |
26 attributes} of a file. There are typically three modes for |
27 access: \underline{\textbf{r}}ead, \underline{\textbf{w}}rite |
27 access: \underline{\textbf{r}}ead, \underline{\textbf{w}}rite |
28 and e\underline{\textbf{x}}ecute. Moreover there are three |
28 and e\underline{\textbf{x}}ecute. Moreover there are three |
29 user groups to which the modes apply: the owner of the file, |
29 user groups to which the modes apply: the owner of the file, |
30 the group the file is associated with and everybody else. This |
30 the group the file is associated with and everybody else. |
31 relatively fine granularity seems to cover many useful |
31 A typical permission of a file owned by \texttt{bob} might look as |
32 scenarios of access control. A typical example of some files |
32 follows: |
33 with permission attributes is as follows: |
33 |
|
34 \begin{center} |
|
35 ${\underbrace{\LARGE\texttt{-}}_{\text{\makebox[0mm]{directory}}}} |
|
36 \;{\underbrace{\LARGE\texttt{r{}-{}-}}_{\text{user}}}\, |
|
37 {\underbrace{\LARGE\texttt{r{}w{}-}}_{\text{group}}}\, |
|
38 {\underbrace{\LARGE\texttt{r{}w{}x}}_{\text{other}}}\;\;\; |
|
39 \LARGE\texttt{bob}\;\;\;\texttt{staff}$ |
|
40 \end{center} |
|
41 |
|
42 \noindent For the moment let us ignore the directory bit. The |
|
43 Unix access rules imply that Bob will only have read access to |
|
44 this file, even if he is in the group \texttt{staff} and the |
|
45 group access permissions allow read and write. Similarly every |
|
46 member in the \texttt{staff} group who is not \texttt{bob}, |
|
47 will only have read-write access permissions, not |
|
48 read-write-execute. |
|
49 |
|
50 This |
|
51 relatively fine granularity of owner, group, everybody else |
|
52 seems to cover many useful scenarios of access control. A |
|
53 typical example of some files with permission attributes is as |
|
54 follows: |
34 |
55 |
35 {\small\lstinputlisting[language={}]{../slides/lst}} |
56 {\small\lstinputlisting[language={}]{../slides/lst}} |
36 |
57 |
37 \noindent The leading \pcode{d} in Lines 2 and 6 indicate that |
58 \noindent The leading \pcode{d} in Lines 2 and 6 indicate that |
38 the file is a directory, whereby in the Unix-tradition the |
59 the file is a directory, whereby in the Unix-tradition the |
156 Notice that the effective identity is not automatically |
177 Notice that the effective identity is not automatically |
157 elevated to \pcode{root}, but the program itself must make |
178 elevated to \pcode{root}, but the program itself must make |
158 this change. After it has done the work, the effective |
179 this change. After it has done the work, the effective |
159 identity should go back to the real identity. |
180 identity should go back to the real identity. |
160 |
181 |
|
182 If you want to play more with access rights in Unix, you can |
|
183 use the program in Figure~\ref{test}. It explicitly checks for |
|
184 readability and writability of files. The \pcode{main} |
|
185 function is organised into two parts: the first checks |
|
186 readability and writability with the permissions according to |
|
187 a potential setuid bit, and the second (starting in Line 34) |
|
188 when the permissions are lowered to the caller. Note that this |
|
189 program has one problem as well: it only gives a reliable |
|
190 answer in cases a file is {\bf not} readable or {\bf not} |
|
191 writable when it returns an error code 13 (permission denied). |
|
192 It sometimes claims a file is not writable, say, but with an |
|
193 error code 26 (text file busy). This is unrelated to the |
|
194 permissions of the file. |
|
195 |
|
196 \begin{figure}[p] |
|
197 \small |
|
198 \lstinputlisting[language=C]{../progs/read.c} |
|
199 \caption{A read/write test program in C. It returns errno = 13 |
|
200 in cases when permission is denied.\label{test}} |
|
201 \end{figure} |
161 |
202 |
162 Despite this complicated semantics, Unix-style access control |
203 Despite this complicated semantics, Unix-style access control |
163 is of no use in a number of situations. For example it cannot |
204 is of no use in a number of situations. For example it cannot |
164 be used to exclude some subset of people, but otherwise have |
205 be used to exclude some subset of people, but otherwise have |
165 files readable by everybody else (say you want to restrict |
206 files readable by everybody else (say you want to restrict |
166 access to a file such that your office mates cannot access |
207 access to a file such that your office mates cannot access a |
167 a file). You could try setting the group of the file to this |
208 file). You could try setting the group of the file to this |
168 subset and then restrict access accordingly. But this does not |
209 subset and then restrict access accordingly. But this does not |
169 help, because users can drop membership in groups. If one |
210 help, because users can drop membership in groups. If one |
170 needs such fine-grained control over who can access a file, |
211 needs such fine-grained control over who can access a file, |
171 one needs more powerful \emph{mandatory access controls} |
212 one needs more powerful \emph{mandatory access controls} as |
172 as described next. |
213 described next. |
173 |
214 |
174 |
215 |
175 \subsubsection*{Secrecy and Integrity} |
216 \subsubsection*{Secrecy and Integrity} |
176 |
217 |
177 Often you need to keep information secret within a system or |
218 Often you need to keep information secret within a system or |