-
Notifications
You must be signed in to change notification settings - Fork 5
/
op.paper
358 lines (291 loc) · 14.5 KB
/
op.paper
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
Op: A Flexible Tool for Restricted Superuser
Access
Tom Christiansen
CONVEX Computer Corporation
POB 833851
3000 Waterview Parkway
Richardson, TX 75083-3851
{uunet,uiucdcs,sun}!convex!tchrist
ABSTRACT
The op tool provides a flexible means for
system administrators to grant trusted users
access to certain root operations without having
to give them full superuser privileges. Different
sets of users may access different operations, and
the security-related aspects of environment of
each operation can be carefully controlled.
One sure way to render a UNIX system unstable is to
distribute the root password to everyone who thinks they
need it. Well-meaning and experienced though these people
may be, they will inevitably introduce anomalies into your
system that will cause it to malfunction in mysterious ways.
You may spend hours or even days trying to determine what
was changed, by whom, and for what reason. This problem
occurs even when all parties involved are experienced system
administrators.
Furthermore, large sites often have computer operators
who attend to the routine tasks of system administration,
such as dumps and restores, tape handling, system shutdown,
and so on. These people may not be sophisticated and you
may not wish them to have complete system privileges to do
their jobs. Denying the superuser password to your cowork-
ers or management is difficult, if not impossible. This
difficulty is particularly true in a technical environment
where programmers may be competent, but insensitive to the
management of a complex system.
The op program, a standard utility provided by CONVEX,
is specifically designed to address this problem. The op
program gives the system manager a means to grant a user or
July 2, 1991
- 2 -
group of users limited access to specific superuser commands
without granting access to all superuser privileges. Care-
ful control of the environment provides both flexibility and
security.
To set up your system, the op program, you begin by
finding out the specific tasks for which system privileges
are deemed necessary when a user requests the superuser
password. Complete access to every command on the system is
usually not required. Using op, the system manager can
designate a set of privileged commands and access lists for
these commands; the system manager, in effect, can grant
limited system privileges beyond those normally available to
a normal user without giving away full superuser privileges.
The op program is not interactive; it functions as a
prefix command, similar to time or nice, whose side-effect
is to alter the user's environment in some fashion. The
functions (or mnemonics) understood by the op program are
listed in the configurable ascii data file /etc/op.access.
This file describes what commands can be performed by the op
program, how they are to be performed, and who is allowed to
perform them. For security reasons, this file should be
owned and readable only by the superuser. Each invocation
of op is logged using syslog(3) with the LOG_AUTH facility
class.
The restrictions can be made as tight as each site
demands, as determined by the system administrator who cus-
tomizes the op.access file. This file contains a mapping of
mnemonics, or operator functions, to the full pathnames of
programs that should be invoked and the arguments that are
allowed, if any. The arguments to the executed program can
be a combination of literal and variable arguments, and res-
trictions can be placed on which values are valid substitu-
tions for the variable arguments. Because some syntactic
checking of the command arguments is possible, running com-
mands under op can be safer than running them directly from
a superuser's shell. This safety feature can prevent pit-
falls like accidentally transposing the file system and tape
device arguments to the dump program (eg. dump 0uf /
/dev/rmt16), which would destroy the file system.
The following set of attributes can be controlled for
each mnemonic by the op program:
o the user id to set
o the group vector to set
o the directory to chdir(2) to
o the root directory to set with chroot(2)
July 2, 1991
- 3 -
o the umask to set
o a list of groups allowed to execute this function
o a list of users allowed to execute this function
o the range of valid arguments for the command, both in
number and value
o any environment variable settings
The fields of the entries in op.access are separated by
white space. Each entry may span several lines and contin-
ues until the next alphanumeric string is found at the
beginning of a line (which is taken to be the next mnemonic,
and thus the beginning of a new entry). Comments may be
embedded beginning with a # character. Each entry in
op.access has the following form:
mnemonic command [ arg ... ] ; [ option ... ]
where the fields are interpreted in the following manner:
mnemonic a unique, alphanumeric identifier for each
operator function.
command the full pathname of the executable to be run by
op when the associated mnemonic is chosen.
arg(s) any arguments, either literal or variable,
needed by command. Literal arguments are simply
specified directly, like specific command
options (0Gun) or files (/dev/rmt20). Variable
arguments are specified here as $1, $2 ... $n;
these are described more fully in the options
section below. $* indicates any number trailing
arguments.
option(s) a set of optional parameters to specify settings
or restrictions for the particular mnemonic,
define variable arguments specified for the com-
mand, and define environment variable settings.
Options are separated by white space and are of
the form keyword=value. The absence of a
specific option means the default is sufficient.
The value can be a single value or a list of
values separated by commas, where appropriate.
There should be no white space in each element
of the value string unless quoted. The keyword
is any of the following types:
uid Set the user id to the value specified.
The value can be a numeric user ID or a
July 2, 1991
- 4 -
login name. The default is root.
gid Set the group ids to the values speci-
fied. Each value can be a numeric group
ID or a group name.
dir Change the current working directory to
the path specified.
chroot Change the root directory to the path
specified using chroot.
umask Set the file creation umask to the octal
value specified. The default is to set
it to 022.
groups Allow any user who belongs to a group
listed here to execute this op function.
The default is not to allow any specific
group.
users Allow any user listed here to execute
this op function. The default is not to
allow any specific users. You may use
the regular expression .* to indicate
that all users may use this mnemonic.
$n defines the nth variable argument speci-
fied in the command arg list. The value
for this type may be a comma-separated
list of regular expressions using
regex(3). option defines the range of
values allowed for the variable argu-
ments. A variable argument specified as
a command arg but not described in the
options section may take on any value.
If an argument does not match any of its
permitted values, then a diagnostic is
printed and the command is not executed.
$* is used in the options section to place
restrictions on the trailing arguments
specified as $* in the args section. If
any of these (possibly many) arguments
do not match, then a diagnostic is
printed, and the command is not exe-
cuted.
$VAR where VAR is the name of an environment
variable. The specified environment
variable is set to the value given
before the command is executed. As a
special case, simply using $VAR with no
= part (as in $USER) means that this
July 2, 1991
- 5 -
environment variable is inherited
unchanged from the caller's shell.
There can also be a special entry in the file beginning
at the first non-comment line that can define default values
to override the builtin defaults listed here, yet still be
overridden by any entry that wants to redefine any of the
keyword fields described above. It should have the follow-
ing format:
DEFAULT keyword_option ...
where keyword_option is a keyword=value strings mentioned
above under options.
It should be noted that if any regular mnemonic entry
defines its own option, the value given for that entry must
explicitly include the item from the DEFAULT line if the
default value is to be included. That is, the options
definitions completely override any defaults; they do not
add to them. In this way, if a value specified on the
DEFAULT line for users or groups (for example) needs to be
"erased" without redefining new values (that is, we want no
users or groups to be allowed to run this mnemonic), then
the default value must be overridden with nothing (as in
users=). For the users and groups fields, such a null set-
ting has the effect of setting the list of allowable users
or groups to be empty. For the other keywords (uid, gid,
dir, chroot, and umask), a null setting leaves that attri-
bute as it is upon invocation of the op program, overriding
any defaults.
This file format may seem complex at first glance, but
is actually intuitive and flexible. An example op.access
file might look like:
July 2, 1991
- 6 -
# first, define the site defaults we want to use here
# we would like the people in `operator' group to be able to execute
# almost everything, so it is easier to put it here than on every line...
# set up default envariables
#
DEFAULT groups=operator $USER $TERM $PATH=/usr/ucb:/usr/bin:/bin
#
# find out who's filled up the disk; anyone may do this
#
full /usr/etc/quot $1; users=.*
#
# filesystem backups
#
daily /etc/dump 5Gun $1; $1=/,/usr[0-9]*,/project
weekly /etc/dump 0Gun $1; $1=/,/usr[0-9]*,/project
#
# tape handling commands
# must include `operator' if we want them to be allowed as well
#
tape /etc/tpc $1 $2; groups=tapeopers,operator users=boss
$1=enable,disable,stop,restart $2=all,unit[01]
#
mounted /etc/tpc mounted unit$1 $2; $1=[0-3]
#
# taking the system down
# $1 shows a good use of regular expressions;
# $2 can be anything, but is required; no instant shutdowns
#
shutdown /etc/shutdown -h $1 $2; $1=+[1-9][0-9]*,[0-9]*:[0-9]*
reboot /etc/shutdown -r $1 $2; $1=+[1-9][0-9]*,[0-9]*:[0-9]*
#
# start up disco daemon
disco /etc/opbin/start_disco; uid=disco gid=proj dir=/scratch
umask=027 groups=geo,disco users=snoopy,linus
$USER=disco $SHELL=/bin/shell
#
# let certain people mount and unmount the removable drive
#
rdsmount /etc/mount $1 $2; groups=operator,swdev,disco users=bob,steve $1=/dev/dd0[a-g] $2=/.*
rdsumount /etc/umount $1; groups=operator,swdev,disco users=bob,steve $1=/dev/dd0[a-g]
#
# allow operators to give files away; notice that they
# they must give at least two args, but may give more
#
chown /etc/chown $1 $2 $*; $1=[a-z0-9][a-z0-9]*
#
# permit development personnel to run install
#
inst /usr/bin/install -o root -g system $1 $2; groups=devel
$2=/bin,/usr/bin,/usr/ucb,/usr/new,/usr/local
#
nfsmount /etc/mount -o timeo=100,hard,intr $1 $2; groups=devel,operator
$1=\([a-zA-Z0-9_]*\):\(.*\) $2=/remote/\1\2
July 2, 1991
- 7 -
Some example command lines using op, given the above
op.access file, might be:
% op full /usr1
% op weekly /usr1
% op tape disable unit0
% op reboot 17:30 "We have to fix our network."
% op disco
% op rdsmount /dev/dd0c ~/mystuff
% op mounted 3 8688
% op chown jim /tmp/bill/*
% op inst less /usr/local
% op nfsmount convexs:/usr/src /remote/convexs/usr/src
Note that the following commands would not work because
they would not match the back-reference specifications in
the nfsmount mnemonic:
op nfsmount convexs:/usr/src /remote/foobar/usr/src
op nfsmount convexs:/usr/src /remote/convexs/src
In summary, the op program allows the system manager to
give out limited system privileges without compromising the
root password. The system can be easily tuned to the needs
of a specific site. The environment in which these commands
execute can be tightly controlled and their arguments
checked for valid values. For security reasons, a log is
kept of all commands run. Careful application of the op
program can result in a stabler system.
July 2, 1991