summaryrefslogtreecommitdiffstats
path: root/chapter_09.xml
blob: a0ab4d21af0559d795e47b2c9fc6a8adad10eca8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
<?xml version="1.0"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "/usr/share/xml/docbook/xml-dtd-4.5/docbookx.dtd">

<chapter>
<title>Filesystem Permissions</title>

<section>
<title>Permissions Overview</title>

<para>
As we've discussed, Slackware Linux is a multi-user operating system.
Because of this, its filesystems are mutli-user as well. This means
that every file or directory has a set of permissions that can grant or
deny privileges to different users. There are three basic permissions
and three sets of permissions for each file. Let's take a look at an
example file.
</para>

<screen><prompt>darkstar:~$ </prompt><userinput>ls -l /bin/ls</userinput>
-rwxr-xr-x 1 root root 81820 2007-06-08 21:12 /bin/ls
</screen>

<para>
Recall from chapter 4 that <application>ls</application> <arg>-l</arg>
lists the permissions for a file or
directory along with the user and group that "own" the file. In this
case, the permissions are rwxr-xr-x, the user is root and the group is
also root. The permissions section, while grouped together, is really
three seperate pieces. The first set of three letters are the
permissions granted to the user that owns the file. The second set of
three are those granted to the group owner, and the final three are
permissions for everyone else.
</para>

<table pgwide="0">
<title>Permissions of /bin/ls</title>
<tgroup cols="3">
  <thead>
    <row>
     <entry>Set</entry>
     <entry>Listing</entry>
     <entry>Meaning</entry>
    </row>
  </thead>
  <tbody>
    <row>
      <entry>Owner</entry>
      <entry>rwx</entry>
      <entry>The owner "root" may read, write, and execute</entry>
    </row>
    <row>
      <entry>Group</entry>
      <entry>r-x</entry>
      <entry>The group "root" may read and execute</entry>
    </row>
    <row>
      <entry>Others</entry>
      <entry>r-x</entry>
      <entry>Everyone else may read and execute</entry>
    </row>
  </tbody>
</tgroup>
</table>

<para>
The permissions are pretty self explainatory of course, at least for
files. Read, write, and execute allow you to read a file, write to it,
or execute it. But what do these permissions mean for directories?
Simply put, the read permissions grants the ability to list the
directory's contents (say with <application>ls</application>). The write
permission grants the ability to create new files in the directory as
well as delete the entire directory, even if you otherwise wouldn't be
able to delete some of the other files inside it. The execute
permission grants the ability to actually enter the directory (with the
<application>bash</application> built-in command cd for example).
</para>

<para>
Let's look at the permissions on a directory now.
</para>

<screen><prompt>darkstar:~$ </prompt><userinput>ls -ld /home/alan</userinput>
drwxr-x--- 60 alan users 3040 2008-06-06 17:14 /home/alan/
</screen>

<para>
Here we see the permissions on my home directory and its ownership. The
directory is owned by the user alan and the group users. The user is
granted all rights (rwx), the group is granted only read and execute
permissions (r-x), and everyone else is prohibited from doing anything.
</para>

</section>

<section>
<title><application>chmod</application>,
<application>chown</application>, and
<application>chgrp</application></title>

<para>
So now that we know what permissions are, how do we change them? And
for that matter, how do we assign user and group ownership? The answer
is right here in this section.
</para>

<para>
The first tool we'll discuss is the useful
<application>chown</application>
(1) command. Using <application>chown</application>, we can (you guessed
it), change the ownership of a file or
directory.  <application>chown</application> is historically used only
to change the user ownership, but can change the group ownership as well.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo</userinput>
total 0
-rw-r--r-- 1 alan users 0 2008-06-06 22:29 a
-rw-r--r-- 1 alan users 0 2008-06-06 22:29 b
<prompt>darkstar:~# </prompt><userinput>chown root /tmp/foo/a</userinput>
<prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo</userinput>
total 0
-rw-r--r-- 1 root users 0 2008-06-06 22:29 a
-rw-r--r-- 1 alan users 0 2008-06-06 22:29 b
</screen>

<para>
By using a colon after the user account, you may also specify a new
group account.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>chown root:root /tmp/foo/b</userinput>
<prompt>darkstar:~# </prompt><userinput> ls -l /tmp/foo</userinput>
total 0
-rw-r--r-- 1 root users 0 2008-06-06 22:29 a
-rw-r--r-- 1 root root  0 2008-06-06 22:29 b
</screen>

<para>
<application>chown</application> can also be used recursively to change
the ownership of all files and directories below a target directory.
The following command would change all the files under the directory
<filename>/tmp/foo</filename> to have their ownership set to root:root.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>chown -R root:root /tmp/foo/b</userinput></screen>

<para>
Specifying a colon and a group name without a user name will simply
change the group for a file and leave the user ownership intact.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>chown :wheel /tmp/foo/a</userinput>
<prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo</userinput>
ls -l /tmp/foo
total 0
-rw-r--r-- 1 root wheel 0 2008-06-06 22:29 a
-rw-r--r-- 1 root root  0 2008-06-06 22:29 b
</screen>

<para>
The younger brother of <application>chown</application> is the
slightly less useful <application>chgrp</application>(1). This
command works just like <application>chown</application>, except
it can only change the group
ownership of a file. Since <application>chown</application> can
already do this, why bother with
<application>chgrp</application>? The answer is simple. Many other
operating systems use a
different version of <application>chown</application> that cannot
change the group ownership, so
if you ever come across one of those, now you know how.
</para>

<para>
There's a reason we discussed changing ownership before changing
permissions. The first is a much easier concept to grasp. The tool for
changing permissions on a file or directory is
<application>chmod</application>(1). The syntax for it
is nearly identical to that for <application>chown</application>, but
rather than
specify a user or group, the administrator must specify either a set of
octal permissions or a set of alphabetic permissions. Neither one is
especially easy to grasp the first time. We'll begin with the less
complicated octal permissions.
</para>

<para>
Octal permissions derive their name from being assigned by one of eight
digits, namely the numbers 0 through 7. Each permissions is assigned a
number that is a power of 2, and those numbers are added together to
get the final permissions for one of the permission sets. If this
sounds confusing, maybe this table will help. 
</para>

<table pgwide="0">
<title>Octal Permissions</title>
<tgroup cols="2">
  <thead>
    <row>
      <entry>Permission</entry>
      <entry>Meaning</entry>
    </row>
  </thead>
  <tbody>
    <row>
      <entry>Read</entry>
      <entry>4</entry>
    </row>
    <row>
      <entry>Write</entry>
      <entry>2</entry>
    </row>
    <row>
      <entry>Execute</entry>
      <entry>1</entry>
    </row>
  </tbody>
</tgroup>
</table>

<para>
By adding these values together, we can reach any number between 0 and
7 and specify all possible permission combinations. For example, to
grant both read and write privilages while denying execute, we would
use the number 6. The number 3 would grant write and execute
permissions, but deny the ability to read the file. We must specify a
number for each of the three sets when using octal permissions. It's
not possible to specify only a set of user or group permissions this
way for example.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo/a</userinput>
-rw-r--r-- 1 root root  0 2008-06-06 22:29 a
<prompt>darkstar:~# </prompt><userinput>chmod 750 /tmp/foo/a</userinput>
<prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo/a</userinput>
-rwxr-x--- 1 root root  0 2008-06-06 22:29 a
</screen>

<para>
<application>chmod</application> can also use letter values along with
<keycap>+</keycap> or <keycap>-</keycap> to grant or deny permissions.
While this may be easier to
remember, it's often easier to use the octal permissions. 
</para>

<table pgwide="0">
<title>Alphabetic Permissions</title>
<tgroup cols="2">
  <thead>
    <row>
      <entry>Permission</entry>
      <entry>Letter Value</entry>
    </row>
  </thead>
  <tbody>
    <row>
      <entry>Read</entry>
      <entry>r</entry>
    </row>
    <row>
      <entry>Write</entry>
      <entry>w</entry>
    </row>
    <row>
      <entry>Execute</entry>
      <entry>x</entry>
    </row>
  </tbody>
</tgroup>
</table>

<table pgwide="0">
<title>Alphabetic Users and Groups</title>
<tgroup cols="2">
  <thead>
    <row>
      <entry>Accounts Affected</entry>
      <entry>Letter Value</entry>
    </row>
  </thead>
  <tbody>
    <row>
      <entry>User/Owner</entry>
      <entry>u</entry>
    </row>
    <row>
      <entry>Group</entry>
      <entry>g</entry>
    </row>
    <row>
      <entry>Others/World</entry>
      <entry>o</entry>
    </row>
  </tbody>
</tgroup>
</table>

<para>
To use the letter values with <application>chmod</application>, you
must specify which set to use them with, either "u" for user, "g" for
group, and "o" for all others. You must also specify whether you are
adding or removing permissions with the "+" and "-" signs. Multiple
sets can be changed at once by seperating each with a comma.
</para>

<screen><prompt>darkstar:/tmp/foo# </prompt><userinput>ls -l</userinput>
total 0
-rw-r--r-- 1 alan users 0 2008-06-06 23:37 a
-rw-r--r-- 1 alan users 0 2008-06-06 23:37 b
-rw-r--r-- 1 alan users 0 2008-06-06 23:37 c
-rw-r--r-- 1 alan users 0 2008-06-06 23:37 d
<prompt>darkstar:/tmp/foo# </prompt><userinput>chmod u+x a</userinput>
<prompt>darkstar:/tmp/foo# </prompt><userinput>chmod g+w b</userinput>
<prompt>darkstar:/tmp/foo# </prompt><userinput>chmod u+x,g+x,o-r c</userinput>
<prompt>darkstar:/tmp/foo# </prompt><userinput>chmod u+rx-w,g+r,o-r d</userinput>
<prompt>darkstar:/tmp/foo# </prompt><userinput>ls -l</userinput>
-rwxr--r-- 1 alan users 0 2008-06-06 23:37 a*
-rw-rw-r-- 1 alan users 0 2008-06-06 23:37 b
-rwxr-x--- 1 alan users 0 2008-06-06 23:37 c*
-r-xr----- 1 alan users 0 2008-06-06 23:37 d*
</screen>

<para>
Which you prefer to use is entirely up to you. There are places where
one is better than the other, so a real Slacker will know both inside
out.
</para>

</section>

<section>
<title>SUID, SGID, and the "Sticky" Bit</title>

<para>
We're not quite done with permissions just yet. There are three other
"special" permissions in addition to those mentioned above. They are
SUID, SGID, and the sticky bit. When a file has one or more of these
permissions set, it behaves in special ways. The SUID and SGID
permissions change the way an application is run, while the sticky bit
restricts deletion of files. These permissions are applied with
<application>chmod</application>
like read, write, and execute, but with a twist.
</para>

<para>
SUID and SGID stand for "Set User ID" and "Set Group ID" respectively.
When an application with one of these bits is set, the application runs
with the user or group ownership permissions of that application
regardless of what user actually 
executed it. Let's take a look at a common SUID application, the humble
<application>passwd</application> and the files it modifies.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>ls -l /usr/bin/passwd \
  /etc/passwd \
  /etc/shadow</userinput>
-rw-r--r-- 1 root root    1106 2008-06-03 22:23 /etc/passwd
-rw-r----- 1 root shadow   627 2008-06-03 22:22 /etc/shadow
-rws--x--x 1 root root   34844 2008-03-24 16:11 /usr/bin/passwd*
</screen>

<para>
Notice the permissions on <application>passwd</application>. Instead of
an <keycap>x</keycap> in the user's execute slot, we have an
<keycap>s</keycap>. This tells us that
<application>passwd</application> is a SUID program, and when we run
it, the process will run as the user "root" rather than as the user
that actually executed it. The reason for this is readily apparent as
soon as you look at the two files it modifies. Neither
<filename>/etc/passwd</filename> nor <filename>/etc/shadow</filename>
are writeable by anyone other than root. Since users need to change
their personal information, <application>passwd</application> must be
run as root in order to modify those files.
</para>

<para>
So what about the sticky bit? The sticky bit restricts the ability to
move or delete files and is only ever set on directories. Non-root
users cannot move or delete any files under a directory with the sticky
bit set unless they are the owner of that file. Normally anyone with
write permission to the file can do this, but the sticky bit prevents
it for anyone but the owner (and of course, root). Let's take a look at
a common "sticky" directory. 
</para>

<screen><prompt>darkstar:~# </prompt><userinput>ls -ld /tmp</userinput>
drwxrwxrwt 1 root root   34844 2008-03-24 16:11 /tmp
</screen>

<para>
Naturally, being a directory for the storage of temporary files sytem
wide, <filename>/tmp</filename> needs to be readable, writeable, and
executable by anyone and everyone. Since any user is likely to have a
file or two stored here at any time, it only makes good sense to
prevent other users from deleting those files, so the sticky bit has
been set. You can see it by the presence of the <keycap>t</keycap> in
place of the <keycap>x</keycap> in the world permissions section.
</para>

<table pgwide="0">
<title>SUID, SGID, and "Sticky" Permissions</title>
<tgroup cols="3">
  <thead>
    <row>
     <entry>Permission Type</entry>
     <entry>Octal Value</entry>
     <entry>Letter Value</entry>
    </row>
  </thead>
  <tbody>
    <row>
      <entry>SUID</entry>
      <entry>4</entry>
      <entry>s</entry>
    </row>
    <row>
      <entry>SGID</entry>
      <entry>2</entry>
      <entry>s</entry>
    </row>
    <row>
      <entry>Sticky</entry>
      <entry>1</entry>
      <entry>t</entry>
    </row>
  </tbody>
</tgroup>
</table>

<para>
When using octal permissions, you must specify an additional leading
octal value. For example, to recreate the permission on
<filename>/tmp</filename>, we would use 1777. To recreate those
permissions on <filename>/usr/bin/passwd</filename>, we would use 4711.
Essentially, any time this leading fourth octet isn't specified,
<application>chmod</application> assumes its value to be 0.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>chmod 1777 /tmp</userinput>
<prompt>darkstar:~# </prompt><userinput>chmod 4711 /usr/bin/passwd</userinput>
</screen>

<para>
Using the alphabetic permission values is slightly different. Assuming
the two files above have permissions of 0000 (no permissions at all),
here is how we would set them. 
</para>

<screen><prompt>darkstar:~# </prompt><userinput>chmod ug+rwx,o+rwt /tmp</userinput>
<prompt>darkstar:~# </prompt><userinput>chmod u+rws,go+x /usr/bin/passwd</userinput>
</screen>







</section>

</chapter>