Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
SUPER(5)		      File Formats Manual		      SUPER(5)

NAME
       super, super.tab	- database of restricted commands for super(1)

DESCRIPTION
       The  super.tab  file  contains the restrictions on who can execute com-
       mands with super(1).  It	may also contain options that modify  the  uid
       and/or  gid under which a command is run; the list of environment vari-
       ables that are discarded	before executing a command, and	 so  on.   The
       reader is expected to be	familiar with the super(1) man page.

       If  you	are trying to avoid reading this lengthy man page, you need to
       know a few simple rules.	 First,	for a user to successfully  execute  a
       command by typing super commandName, the	minimum	entry in the super.tab
       is something like
	    commandName	  FullPathToCommand  userName
       For example, the	entry
	    cdmount   /usr/local/bin/cdmount  wally,dolly
       says that users wally and dolly may execute the	/usr/local/bin/cdmount
       program by typing super cdmount.

       Second,	when  you  define options in the super.tab file, remember that
       all options are orthogonal to each other, and it	doesn't	matter in what
       order they appear on a control line.  Third, global options (defined on
       a :global or :global_options line) take effect  immediately  after  the
       defining	line, are valid	until the end of the input or until there is a
       countermanding global option or pattern,	and are	 overridden  by	 local
       (per-command) options, which are	defined	on a regular control line.

       Although	super has a great many options that you	can set	inside the su-
       per.tab file, none of them are required for security, so	you don't have
       to be intimately	familiar with this entire document in order to use su-
       per securely.  The most important options that you will	probably  want
       to  use	are (a)	a logging option like logfile=xxx or syslog=y; and (b)
       patterns=shell, so that the default  regular-expression	interpretation
       of  wildcards  is  changed to the more convenient shell-style glob pat-
       terns.

       Unless modified with options in the super.tab file, super executes com-
       mands  using effective uid root;	unchanged real uid and gid; no supple-
       mentary groups; no open file descriptors	save 0,	1, and 2; no  environ-
       ment  variables except a	few with safe values (see super.1); and	signal
       handling	reset to the default.

       When super uses a command from a	user-supplied super file (.supertab in
       the  user's  home directory) these rules	are modified: the real and ef-
       fective uid and gid are set to the owner	of the .supertab file, and the
       supplementary groups are	set to the user's login	groups.

       If  the	special	 supplementary file named super.init exists, it	is im-
       plictly include at the start of super.tab  and  every  .supertab	 file.
       The  file  resides in the same directory	as super.tab and must be owned
       by root,	and should be world-readable.  This provides a uniform config-
       uration	file  applied  to every	super-executed command.	 Note that the
       configuration file should contain entries that are appropriate for  use
       in both the super.tab file and any per-user supertab file.  It is not a
       good idea to include commands in	the  super.init	 file.	 The  variable
       IS_USERTAB  is  defined to be ``yes'' if	super is processing a per-user
       .supertab file, and ``no'' otherwise.  The following  pair  of  entries
       could  be  used	in a super.init	file to	allow different	initialization
       for regular use and per-user use:

	      :if $IS_USERTAB == yes	:include /etc/super.init.per-user
	      :if $IS_USERTAB != yes	:include /etc/super.init.as-root

       (The use	of variables and conditional expressions is  explained	below,
       in the sections Variables and Conditionally-included Control Lines, re-
       spectively.)

       The super.tab file is formatted as a series of  control	lines  of  the
       form

	    CmdPat  FullPath \
			 Options PermittedUsers	PermittedTimes
       or
	    CmdPat1::FullPath1 CmdPat2::FullPath2 ... \
			 Options PermittedUsers	PermittedTimes
       or
	    :BuiltinCmd	arguments

       The  Options,  PermittedUsers, and PermittedTimes may be	mixed together
       in any order.  At least one PermittedUsers field	is required, but  nei-
       ther  Options  nor PermittedTimes are required.	For each control line,
       Super matches the following:

	      o	the user-entered command to a CmdPat;

	      o	the {user,group,host} triplet to a PermittedUsers entry; and

	      o	the current time to a PermittedTimes entry (the	 default  per-
		     mits any time).

       If  these  conditions  are  not	satisfied, super ``falls through'' and
       tries the next control line.

       For example, the	entry

	      renice /etc/renice jack@hill jill@bucket time~8-17

       specifies that between hours 8:00 and 17:00, user Jack can  renice  any
       process on host hill, and user Jill can do so on	host bucket, by	simply
       typing super renice <args>  .

       Control lines begin in column 1,	and the	 fields	 are  whitespace-sepa-
       rated.  Note that you can either	use a single CmdPat and	FullPath, sep-
       arated by whitespace, or	you can	use a series of	them  in  one  control
       line by putting `::' between each CmdPat	and FullPath pair.

       Whitespace  may	be included in a field by enclosing text in single- or
       double-quotes.  The quoting is shell-like, in the sense that quotemarks
       don't  have  to	surround  the entire field, and	you can	switch between
       quotemark types in a  single  entry.   For  instance,  X"a b"Y'd	e'  is
       equivalent  to  "Xa bYd e".   Comments begin with a `#' and continue to
       the end of a line.

       There can also be blank or comment lines	without	any control data.

       A control line may be continued by preceding the	newline	with  a	 back-
       slash,  and  indenting the continuation line with whitespace.  When the
       multiple-line entry is read, the	text just before the backslash-newline
       is not modified (any whitespace before the backslash will be kept), and
       the backslash-newline-whitespace	sequence is either eliminated entirely
       or  treated  as	whitespace.   The  rule	is simple: following a letter,
       digit, or underscore, it	is treated as whitespace.   Otherwise,	it  is
       eliminated.  This means that

	      Cmd  File	 user1\
			 user2\
			 user3

       is equivalent to

	      Cmd  File	 user1 user2 user3

       On the other hand,

	      Cmd  File	 {user1,\
			 user2,\
			 user3}

       is equivalent to

	      Cmd  File	 {user1,user2,user3}

       That is,	the sensible interpretation is done in both cases.

       The  indentation	 requirement  for continuation lines helps super catch
       typos.  Comments	may be placed before each backslash-newline pair,  not
       just at the end of a continued control line.

The CmdPat Field
       In response to the user typing

	      super cmd	[ args ],

       the  cmd	 is  searched  for  in the super.tab file.  The	cmd is matched
       against each pattern CmdPat.

       Basic Use: Simple Command Patterns without Wildcards.

       Typically, a CmdPat just	uses plain characters without any special pat-
       tern-matching  characters,  so  a  cmd  must  be	the same as the	CmdPat
       string.	For example:

	      skill /usr/local/bin/skill   user1 user2 user3

       Here, any user in the list {user1, user2, user3}	may type  super	 skill
       to execute /usr/local/bin/skill.

       Advanced	Use: Command Patterns with Wildcards.

       More  generally,	 a CmdPat can be either	an ed-style pattern (``regex''
       -- the BSD 4.x syntax used in the re_comp()/re_exec() routines),	 POSIX
       regular	expressions, or	a Bourne-shell-style pattern.  You can set the
       pattern style using the global option patterns (see  below).   The  de-
       fault  is  ``regex''  for historical reasons; however, shell-style pat-
       terns are easier	to use without	errors,	 and  most  sites  should  use
       shell-style  patterns.	In all cases the patterns are extended to sup-
       port csh-style brace expansion.	For instance, a{x,y,z}b	stands for the
       set  of	patterns  axb  ayb  azb.   Don't put any whitespace inside the
       braces!

       For convenience,	there is always	an implied set of braces around	an en-
       tire pattern.  This means that any comma-separated list a,b,c is	inter-
       preted as {a,b,c}, and is very helpful so that you don't	have to	 worry
       about  getting braces just right	when you build complex lists of	out of
       (say) variables containing other	lists of users.

       All pattern matching is ``anchored'': patterns are forced to match  the
       entire cmd string.

       If  the CmdPat is matched and the other conditions are met (such	as the
       user being in the PermittedUser list to execute this command), FullPath
       gives  the  name	 of  the actual	command	that will be executed with ex-
       ecve().	If FullPath contains an	asterisk, the asterisk	is  first  re-
       placed by the user's cmd.

       If  you	put  special  pattern-matching characters into the CmdPat, but
       don't put an asterisk into FullPath, you	have simply given more ways  a
       user  can  execute  the	same FullPath.	This isn't useful, and in fact
       isn't a good idea at all.  The power of using patterns  in  the	CmdPat
       comes  when  FullPath includes an asterisk.  For	instance, a SysV-based
       host might have an entry	in the super.tab file that looks like:

	      /usr/bin/{lp,lpstat,disable,enable,cancel} * \
			     :operators	uid=0

       This would allow	anybody	in the "operators" group to have  root	access
       to the line printer commands (the uid=0 tells super to set the real uid
       to 0, not just the effective uid).  For instance, if the	user typed:

	      super /usr/bin/disable some_printer

       then the	FullPath (``*'') would be replaced by /usr/bin/disable,	 which
       would be	the command to exec.

       More conveniently, the super.tab	file could have	a line like:

	      {lp,lpstat,disable,enable,cancel}	/usr/bin/* \
			     :operators	uid=0

       In this case, the user can type

	      super disable some_printer

       The asterisk-replacement	ability	also lets a user execute any of	an en-
       tire directory of commands, using a super.tab entry like	the following:

	      op/* /usr/local/super/scripts/* :operators uid=0

       In this case, the user can type

	      super op/xyz

       and super will execute /usr/local/super/scripts/op/xyz.

       The asterisk-replacement	capability is useful but  potentially  danger-
       ous,  because  it  may  unintentionally	open  the door to programs you
       hadn't intended to give away.  It is a sensible precaution to  restrict
       asterisk-replacement  to	 entries  where	 the  valid-user list includes
       trusted users only.

       If you completely trust some users, but want logging of all actions ex-
       ecuted as root, you could use:

	      /*   *   ReallyReallyTrustedUsers
       or
	      /.*   *	ReallyReallyTrustedUsers

       (depending   on	 whether   patterns=shell,   patterns=regex,  or  pat-
       terns=posix).

       The trusted users can now execute any command.  Note that  the  pattern
       begins with a slash, to ensure that the cmd must	be an absolute path --
       this helps avoid	accidental execs of the	wrong program.

       If you were really going	to give	everything away	as shown above,	 you'd
       probably	 want  to  exclude  any	 public-area workstations, require the
       trusted users to	periodically give their	passwords, and	set  the  real
       uid=root	 (instead  of  just  the effective uid), so the	entry might be
       modified	to read	something like:

	      /*   *   TrustedUsers \
		       !{PatternsOfPublicWorkstations} \
		       password=y timeout=5 uid=0

The FullPath Field
       The FullPath field gives	the name of the	actual command	that  will  be
       executed,  and  if  it  contains	an asterisk, the asterisk is first re-
       placed by the user's cmd	string.	 The FullPath can optionally contain a
       list  of	 initial  arguments  that  precede any arguments passed	by the
       user.  For example,

	      xyz  "/usr/local/bin/blah	-o1 -o2	-xrm 'a	b c'" ...

       specifies that when a valid user	types super xyz, the command  to  exe-
       cute is /usr/local/bin/blah and its arguments will be
	      argv[1]: -o1
	      argv[2]: -o2
	      argv[3]: -xrm
	      argv[4]: a b c
       followed	 by any	arguments that the user	put on the super command line.
       Note: asterisk replacement is only done on the  filename	 part  of  the
       FullPath,  not  on  the arguments.  You can safely include asterisks in
       the argument list.  For security, the user's cmd	may  not  contain  any
       whitespace or backslashes.

       The  FullPath  string is	parsed using rules similar to the Bourne shell
       rules for backslashes in	quoted strings,	namely:
	      (a) backslash-newline is discarded;
	      (b) Otherwise, if	outside	a quoted substring,  \x	 ->  plain  x,
	      which  will not be treated as a delimiter, quotemark, or comment
	      character;
	      (c) Otherwise, inside a quoted substring of FullPath:
		     \\	-> \;
		     \q	-> q, where q is the quote character that encloses the
		     FullPath string;
		     other backslashes are preserved: \x -> \x.

       After  writing  a  command with such backslash escapes, you should cer-
       tainly use ``super -d cmd'' to check that your args are being parsed as
       expected	before you offer this command to your users.

       The  same  cmd  can  be	listed several times in	the super.tab file, in
       which case the first entry that allows the user to execute the  command
       is chosen.  The EXAMPLES	section	shows how this can be useful.

Permitted Users
       Permitted users are those who may execute the specified Cmd's.  Entries
       for any number of permitted users are given after the CmdPat and	 Full-
       Path  fields.  Local options -- options that apply to this command only
       -- may also appear anywhere after the FullPath.	 Options  are  distin-
       guished	from  permitted	 users	because	 options  all  have  the  form
       key=value, whereas permitted-user entries  may  not  contain  unescaped
       equal signs.  Each whitespace-separated word is a pattern in one	of the
       formats

	    o	 [user~]user[:][@host]

	    o	 [user~]:group[@host]

	    o	 [user~]user[:group][@host]

       Note that the user~ part	is optional.  The user's login name must match
       the  user  pattern;  the	user must belong to a group whose name matches
       the group pattern; and the hostname must	match the  host	 pattern.   If
       the  user, group, or host part is not given, there are no corresponding
       restrictions.

       If the user is root, super acts as if all permitted-user	 patterns  are
       preceded	 by  the pattern user~root -- that is, root's rule is default-
       allow, instead of the default-deny rule that applies  to	 all  ordinary
       users.

       By  default,  the ``group'' field is first matched against named	groups
       to which	the user belongs, and then against the user's decimal  gid  --
       this  allows the	user to	be put in a group in the /etc/passwd file that
       isn't given a name in the /etc/group file.  (If you want	to change  the
       rules  for  using  decimal  gid,	 see  the use of MATCH_DECIMAL_UID and
       MATCH_DECIMAL_GID in super.c for	details.)

       Since you can restrict users to particular hosts,  a  single  super.tab
       file  can be shared among many different	machines.  If the host part is
       of the form +xyz, then xyz is interpreted as a netgroup	name  and  any
       host in netgroup	xyz is matched.	 In that case, xyz is taken literally,
       and not interpreted as a	pattern	to be matched.	Note: netgroup	lookup
       is only implemented if the function innetgr() is	available.

       If  the	host  part doesn't match the hostname, it might	be because the
       pattern and actual hostnames contain two	different (but both valid) in-
       complete	 versions  of  the fully-qualified domain name (FQDN).	By de-
       fault, if the host part fails to	match the hostname, the	FQDN is	looked
       up  and all of the ways of naming the host are matched against the pat-
       tern.  For example, if the FQDN is  spacely.sprockets.com,  super  will
       first  try  spacely.sprockets.com,  then	spacely.sprockets, and finally
       spacely.	 This can be turned off; see option gethostbyname.  (You might
       want to turn it off because using nameserver lookup can reduce security
       a bit --	your host may query a nameserver on another host to obtain the
       FQDN,  and  (a)	that  nameserver or an intermediate host along the way
       could have been subverted, or (b) another host  could  impersonate  the
       nameserver.  In either case your	computer could receive incorrect host-
       names.)

       The patterns for	valid users, groups, and hosts follow the  same	 rules
       for  the	 CmdPats, described above: they	can be entered with either ed-
       style or	Bourne-shell-style patterns (depending on the setting  of  the
       patterns	 global	option); csh-style brace expansion is allowed; and all
       pattern matching	is ``anchored'': patterns are forced to	match the  en-
       tire username, groupname, or hostname.

       To  make	 it easy to exclude some users/groups/hosts, any of these pat-
       terns can be negated by prefixing the pattern with `!'.	If  a  negated
       pattern is matched, the user may	not execute the	command, even if there
       was a previous non-negated pattern that the user	matched.  All patterns
       are read	left-to-right, and the last matched pattern ``wins''.  Thus if
       the user/group/host list	is

	      j.* !jo
	      or
	      user~j.* !user~jo

       then the	first entry allows any username	beginning with `j' to  execute
       the  command,  but the second entry disallows user `jo'.	 If entered in
       the reverse order,

	      !jo j.*

       then the	second entry, `j.*',  allows  all  users  beginning  `j',  and
       therefore the first entry has no	effect.

Permitted Times
       The  time condition restricts the days and times	during which this com-
       mand may	be matched.  If	the execution time isn't acceptable, then  su-
       per ignores the control line, and ``falls through'' to inspect the next
       entry, just as it does if the  user/group/host  aren't  acceptable.   A
       time condition looks like:
	    time~pattern

       with patterns that look like:

	      Pattern			    Example
	      hh[:mm]-hh[:mm][/dayname]	    13:30-17/monday
	      {<,>,<=,>=}hh[:mm][/dayname]  <17/tues
	      dayname			    Friday

       The  first  form	explicitly specifies an	interval during	which the com-
       mand may	be used.  Times	may not	go past	midnight; to specify the night
       between Monday and Tuesday, you must do something like:
	      time~{17:30-24:00/mon,0-8/tues}

       The  second form	for time patterns allows you to	use logical operators.
       The Monday-night	example	could equally have been	rendered as:
	      time~{>17:30/mon,<8/tues}
       (There is a tiny	difference in the two examples above: in the first ex-
       ample,  the  time range includes	17:30 and 8:00;	in the second example,
       the time	range is 17:31-07:59.  Use time~{>=17:30/mon,<=8/tues} to make
       the interpretation identical to the first example.)

       If  there  are  a  series of time patterns, they	are evaluated left-to-
       right, and the rightmost	matching pattern is used.  To permit execution
       between	17:30  Monday and 8:00 Tuesday,	but exclude 0:00 to 1:00 Tues-
       day, use:
	      time~{>=17:30/mon,<=8/tues}  !time~{0-1/tues}

       By default, valid daynames are English, but if your system supports the
       setlocale(3)  function,	the  global option lang=zzz will set the valid
       names to	those of locale	zzz.  Valid daynames are either	(a)  the  full
       names  of the chosen language; (b) an official abbreviated day name for
       that language; (c) a 3-or-more character	abbreviation of	the full week-
       day;  or	 (d) *,	meaning	any day.  (You can check on super's valid day-
       names by	executing super	-d, which will show the	default	names  of  the
       weekdays	 at  or	near the top of	its debugging output, and show the new
       weekday names that take effect when  the	 lang=zzz  option  is  encoun-
       tered.)

       Time patterns have a special defaulting rule when the execution time is
       not in one of the intervals in the time list:
	      o	if all time patterns are negated, super	permits	 execution  at
	      any time not in one of the listed	intervals;
	      o	 otherwise, there is at	least one non-negated pattern, and su-
	      per defaults to deny execution at	times  outside	the  specified
	      acceptable intervals.
       The  reason  is	that the natural interpretation	of a series of negated
       conditions, such	as
	      !time~{0-8,17-24}	!time~{sat,sun}
       is to infer that	all other times	are acceptable for execution.  On  the
       other hand, if there are	any ordinary, non-negated times, such as
	      time~8-17/{mon,tues,wed,thu,fri}
       the  natural  interpretation is that any	times not explicitly mentioned
       are not acceptable.

       Note that explicit braces are important in the  above  list.   If  they
       were missing, the implied braces	around the entire pattern would	render
       this equivalent to
	      time~8-17/mon time~tues time~wed time~thu	time~fri
       That is,	the permitted times are	8-17h on Monday, and any time on Tues-
       day through Friday.

Global Conditions
       Global  options and conditions affect the overall super processing.  To
       set them, you must use a	line like

	      :global		  Global Options And Patterns
       or
	      :global_options	  Global Options And Patterns

       For backwards compatibility, you	can alternatively use

	      /		/	  GlobalOptionsAndPatterns

       but this	use is discouraged.

       These so-called ``global'' options and conditions actually take	effect
       immediately  after  the	line on	which they appear, and are valid until
       the end of the input or until there is a	countermanding	global	option
       or pattern.  To have a global option or pattern affect the entire file,
       you must	place it as the	first non-comment line of the super.tab	file.

       If there	are any	 PermittedUser	or  PermittedTime  conditions  on  the
       global settings line, they are applied to each following	command	in the
       super.tab file.	The conditions look like

	      :global	cond cond ...  <> cond cond ...

       PermittedUser and PermittedTime conditions to the left  of  ``<>''  are
       processed  before the local (per-command) conditions; conditions	to the
       right of	``<>'' are processed after  the	 per-command  conditions.   If
       ``<>''  is missing, all conditions are processed	after the local	condi-
       tions.  Example 1:

	      :global	jan <> !@+badhosts

       says that user jan can usually execute any command, but under  no  cir-
       cumstances  will	 a user	on any host in netgroup	badhosts be allowed to
       execute any command.  (User jan will not	be allowed to execute  a  com-
       mand  if	the per-command	conditions disallow it,	or if jan is on	one of
       the badhosts computers).

       Example 2:
	      :global	!root <>

       changes root's default setting from default-allow to default-deny, just
       like  ordinary  users.	Root will only be given	execute	permission for
       entries that explicitly allow root on the per-entry line.

       Global PermittedUser (PermittedTime) conditions take effect on the line
       on  which  they	are  defined, and are good until another set of	global
       PermittedUser  (PermittedTime)  conditions  is	entered	  on   another
       :global_option line.  That is, a	new global condition line replaces any
       previous	global conditions.

       One sensible approach to	using global conditions	is to  put  conditions
       that  allow users to execute commands before the	per-command conditions
       are processed, and to put  negating  patterns  (for  users/groups/hosts
       that are	never to be allowed to execute anything) after the per-command
       conditions.

       (Global options are discussed below, together with local	options).

Conditionally-included Control Lines
       Control lines can be conditionally included by using  the  :if  control
       line.  This can be helpful when using a single super.tab	file for hosts
       with different architectures, or	hosts in different NIS	domains,  etc.
       The syntax is:

	      :if  left	  op   right	 moreText

       The  expression	left  op  right	is evaluated, and if true, moreText is
       evaluated as an ordinary	control	line.  The valid comparison  operators
       are:

	    o	 ==   string equality
	    o	 !=   string inequality
	    o	 ~    glob match string	left against pattern right
	    o	 !~   negated glob-match.
       For  example,  you  could  include  a  file  of	commands only valid on
       Sun4-type machines as follows:

	      :if $UNAME_MACHINE ~ sun*	\
		       :include	 /Path/To/Sun4/File
       (UNAME_MACHINE is a variable automatically defined by  super;  see  the
       following section on variables.)

       If  you	wanted to exclude Sun4c-type machines from using the file, you
       could modify this to be:

	      :if $UNAME_MACHINE ~ sun*	\
		  :if $UNAME_MACHINE !=	sun4c \
		       :include	 /Path/To/Sun4/File

       There are no boolean operators provided,	but note that there is an  im-
       plicit boolean and available by concatenating :if commands, as shown in
       the second example above.

Variables
       Super offers variables to make it easier	to handle entries that are du-
       plicated	 or  are  constructed out of other entries.  Variables are de-
       fined by	typing

	      :define VariableName VariableDefinition

       or they may be imported from the	environment by using

	      :getenv [EnvVarName...]

       If you use the :getenv command, then the	values of any  imported	 envi-
       ronment	variables  may only contain the	following ``safe'' characters:
       -/:+._a-zA-Z0-9.	 If ``bad'' characters are found in a value,  the  en-
       tire  value is replaced with an empty string.  Note that	these imported
       variables do not	enter the environment of any  executed	command;  they
       simply become part of the super.tab variable set.

       The  VariableName should	be made	up only	of letters, digits, and/or un-
       derscore.  (You can actually use	any characters	you  wish,  but	 super
       doesn't	promise	 to  work  correctly if	you use	characters outside the
       standard	set.)

       The VariableDefinition begins at	the first non-whitespace character af-
       ter  the	 VariableName  and continues up	to but not including the final
       newline.	 Comments embedded on  the  variable  definition  line(s)  are
       deleted	before	the variable definition	is stored.  A variable defini-
       tion may	be continued across multiple lines by preceding	 each  newline
       with  a backslash, and indenting	the continuation line with whitespace.
       Just as for regular control lines, the backslash-newline-whitespace se-
       quence  is  treated as whitespace if it follows a letter, digit,	or un-
       derscore; otherwise, it is eliminated.  For example,

	      :define  Users   user1,\
			       user2,\
			       user3
       and
	      :define Users   user1,user2,user3

       are equivalent definitions.

       Unlike Makefiles, the variable definitions are not  scanned  first  and
       then  the file re-scanned.  Instead, variables take effect at the point
       they are	defined, and remain in effect until they are re-defined	or end
       of  file	 -- thus variables definitions must precede their first	use in
       the file.

       Variables may contain other variables (which must have already been de-
       fined).	 Variable  substitution	 is done when a	line is	first read.  A
       line is never re-scanned	after variable substitution.

       Variables are used in a file by typing

	      $VariableName

       or

	      $(VariableName)

       The special variable $$ is replaced by a	single ``$''.  Any other  name
       $X (where X is not a letter, digit, or underscore) is an	error.

       Because	a  line	 is  never re-scanned after variable substitution, the
       following sequence:

	      :define A	$$
	      :define B	A
	      :define C	$B $$B
	      $C

       defines C to be simply ``A $B''.

       Variables can be	helpful	in grouping users or hosts together.  For  ex-
       ample,  you  might restrict access to a command so that it can't	be run
       from a public-access workstation:
	      :define Room103_WS hosta,hostb,hostc,hostd
	      :define Room105_WS hoste,hostf,hostg,hosth
	      :define Room106_WS +nonprivate
	      :define PublicWorkstations $Room103_WS,$Room105_WS,$Room106_WS
	      SomeCmd FullPathHere !@$(PublicWorkstations)

       In the above example, we	have taken advantage  of  the  implied	braces
       that  are always	placed around any pattern, so that the comma-separated
       list of workstations is brace-expanded into !@hosta !@hostb ... !@hoste
       !@hostf ... !@+nonprivate.

       Some variables are automatically	defined	by super.

       After  super  determines	 whether it is processing a per-user .supertab
       (see super(1)), it defines IS_USERTAB to	be ``yes'' if  super  is  pro-
       cessing	a  per-user  .supertab file, and ``no''	otherwise.  The	allows
       the super.init to act differently depending on how it is	being invoked.

       When the	top-level super.tab file is opened, SUPER_OWNER	is set to  the
       login name of the owner,	and SUPER_HOME is set to the home directory of
       the owner.  This	can be useful in per-user .supertab files,  especially
       when  they  include  files shared among several accounts.  For example,
       each person's .supertab file could be simply

	      :include /opt/proj/common.supertab owner=cristy

       Then, the /opt/proj/common.supertab file	can use	entries	like the  fol-
       lowing:

	      :global logfile=$SUPER_HOME/.superlog
	      *	/project/tools/$SUPER_OWNER/* :toolgroup

       Because the SUPER_HOME and SUPER_OWNER variables	apply to the top-level
       per-user	files, they always refer to per-user locations.

       Super defines the built-in variable CALLER to be	the the	login name  of
       the of account invoking super, and CALLER_HOME is the home directory of
       $CALLER.	 Sample	use:
	      sam  /usr/sbin/sam  group~operator  uid=0	\
				  env=DISPLAY \
				  setenv=XAUTHORITY=$CALLER_HOME/.Xauthority
       Here, the operator group	can execute sam	as root, and the GUI will dis-
       play  at	 the  caller's display (due to the use of env=DISPLAY).	 Since
       the XAUTHORITY environment variable is set to the caller's  .Xauthority
       file,  this will	give the caller	access to the same display(s) to which
       s/he already has	access.

       The following variables are defined when	super starts up.  They can  be
       useful  in  conditionally-included  lines  (:if	lines).	  If your host
       doesn't supply these functions, or doesn't support some of  the	values
       that  super tries to fetch, the corresponding variable will be initial-
       ized to an empty	string.	 (Use super -b to print	the names  and	values
       of  all	builtin	 variables.  This makes	it simple to see what variable
       values to check in :if lines.)

       From the	gethostname() or sysinfo() function:
	    o HOSTNAME		  Hostname, possibly canonicalized.
	    o HOST		  Hostname, short (unqualified).

       From the	getdomainname()	function:
	    o NIS_DOMAIN	  domain set for NIS purposes.

       From the	sysinfo() function:
	    o SI_SYSNAME	  Name of operating system.
	    o SI_HOSTNAME	  Name of node.
	    o SI_RELEASE	  Release of operating system.
	    o SI_VERSION	  Version field	of utsname.
	    o SI_MACHINE	  Kind of machine.
	    o SI_ARCHITECTURE	  Instruction set arch.
	    o SI_HW_SERIAL	  Hardware serial number.
	    o SI_HW_PROVIDER	  Hardware manufacturer.
	    o SI_SRPC_DOMAIN	  Secure RPC domain.
	    o

       From the	uname()	function:
	    o UNAME_SYSNAME	  Operating system name.
	    o UNAME_NODENAME	  The nodename.
	    o UNAME_RELEASE	  Operating system release.
	    o UNAME_VERSION	  Operating system version.
	    o UNAME_MACHINE	  Machine hardware name	(class).

Options
       The configuration file can specify a wide variety of options,  such  as
       requiring  the  user's  password	before executing some commands,	or re-
       stricting the command-line arguments to match certain patterns.

       Options are handled very	differently from  conditions  (conditions  in-
       clude  user,  group,  host,  and	time).	If a control line's conditions
       aren't met, super falls through and tries the next control line in  the
       file.  After finding an acceptable control line,	super will execute the
       command if the options are satisfied; otherwise,	it stops  and  doesn't
       search the super.tab file any further.

       Options	can  be	divided	into (a) local options,	which are defined on a
       regular control line, and apply only to	that  control  line;  and  (b)
       global options, which are defined on a :global or :global_options line,
       take effect immediately after the line, and are valid until the end  of
       the input or until there	is a countermanding global option or pattern.

       All  options  are  orthogonal to	each other.  It	doesn't	matter in what
       order they appear on a control line.

       Some options can	be given as either local or global options.   If  both
       are used, the local setting overrides the global	one.

       Two special names can be	used with any of the options that take user or
       group  ids  as  arguments:  owner=xxx,  uid=xxx,	  euid=xxx,   gid=xxx,
       egid=xxx, u+g=xxx, groups=xxx, addgroups=xxx.  These names are <owner>,
       meaning the owner of the	file to	be executed  (or  the  owner's	group,
       whichever  is  appropriate  in  the context); and <caller>, meaning the
       owner or	group of the user calling super.  The angle brackets are  lit-
       erally  part  of	 the name.  These have the same	values as the built-in
       variables CALLER	and OWNER (see the Variables section, above).  For ex-
       ample, the options
	      gid=Foo uid=<caller>
       would change the	group to Foo, but leave	the uid	unchanged.

       The recognized options are:

       Group 1.	 Options Affecting How Superfiles Are Read and Processed.

       patterns=xxx
	      (Global)	Specifies the pattern-matching type for	conditions and
	      options.	The string xxx must be one of:

	      posix -- patterns	are POSIX regular expressions.	 You  can  use
		     ``posix/extended''	  for  extended	 regular  expressions;
		     ``posix/icase'' for case-insensitive regular expressions;
		     or	 ``posix/extended/icase'' for both.  See your regular-
		     expression	man pages for details.

	      regex -- patterns	are ed-style regular  expressions,  using  the
		     rules     embodied	    in	   the	   BSD 4.x    routines
		     re_comp()/re_exec(), with the addition of csh-style brace
		     expansion.	  This	is the default for historical reasons,
		     but most people prefer to use shell-style patterns	 here,
		     and  it  is  recommended that you put patterns=shell (see
		     below) in your global options list.

	      shell -- patterns	are approximately Bourne-shell style, with the
		     addition  of  csh-style  brace  expansion and the special
		     [[chars]] pattern.	 The patterns are formed from:

		     \x	  force	x to be	a plain	character;

		     ?	  matches any single character;

		     *	  matches any sequence of 0 or more chars;

		     [chars]   matches any single character in the set;

		     [^chars]  matches any single char NOT in the set;

		     [[chars]] When the	pattern	begins with [[,	and ends  with
			    ]],	 then  each  and every character in the	string
			    must match	the  ordinary  square-bracket  pattern
			    [chars] (or	[^chars]).

		     ^pat inverts  the	sense  of the match -- the string must
			    NOT	match the pattern.

       lang=zzz
	      (Global) This option sets	the language  used  for	 weekdays  (in
	      time conditions).	 Here, zzz may be any locale available on your
	      host.  For example, lang=de would	typically cause	super  to  use
	      German names.  The default is the	C locale, hence	English	names.

       relative_path=y|n
	      (Global)	If  y,	FullPathNames can be relative instead of abso-
	      lute.  By	default	this is	disallowed, because it is  almost  al-
	      ways a very foolish (unsafe) thing to do.

       group_slash=y|n
	      (Global) If y, group names can contain a slash.  By default this
	      is disallowed, so	that super can catch certain typos in the  su-
	      per.tab file.  (Namely, super can	catch errors in	which an entry
	      is of the	form Cmd:File instead of the required Cmd::File.   The
	      trouble  is  that	 Cmd:File looks	syntactically like user:group,
	      and can therefore	be mistaken for	a  valid  part	of  a  control
	      line.   But the filename will contain a slash -- unless you have
	      unwisely enabled the  relative_path  option  --  so  disallowing
	      slashes allows super to flag the line as syntactically invalid.)

       gethostbyname=y|n
	      (Global)	Enables	or disables the	use of gethostbyname() to find
	      the fully-qualified domain name (see the discussion in the  Per-
	      mitted  Users section, which describes the security issues asso-
	      ciated with enabling this	option.)  Default:  enabled  (if  your
	      host supports gethostbyname()).

       Group 2.	 Logging Options.

       logfile=fname
	      (Global)	Enables	 logging  to a local file.  Each invocation of
	      super (aside from	ones for help)	generates  an  entry  in  file
	      fname.

       loguid=xxx
	      (Global)	If  logging is enabled with logfile=fname, the logfile
	      will be opened for writing using uid=xxx (can be either a	 user-
	      name  or	numeric	uid).  This option allows you to have the file
	      created/opened under another uid that does have  cross-host  ac-
	      cess,  such  as  the  uid	 of  a system manager.	(See timestam-
	      puid=xxx for additional comments).  Default: loguid=0.

       mail="mail-command"
	      (Local|Global) Notices of	super failures are piped to the	 shell
	      command mail-command.  This is independent of the	setting	of the
	      logfile and syslog options.  For instance, mail="mail  -s	 Super
	      joeblow"	will cause error messages to be	mailed to user joeblow
	      (on some systems you may need to	substitute  mailx  for	mail).
	      Note:  the mail-command is executed by passing it	as an argument
	      to popen(3).  This is safe to execute because of the clean envi-
	      ronment assured by super.

       mailany="mail-command"
	      (Local|Global) This is identical to the mail option, except that
	      mailany sends notification of successful invocations as well  as
	      errors.

       rlog_host=hostname
	      (Global)	Tells  super  which host's syslog daemon is to receive
	      log messages when	option syslog=y	is enabled.  The option	has no
	      effect  if used after the	first message is logged: once the log-
	      ger has been opened, it is not re-opened	if  the	 rlog_host  is
	      changed.	Default: the local host.  Note:	One could instead con-
	      figure the syslog.conf file to forward the messages to a central
	      machine.

       syslog=y|n
	      (Global) Logging information is passed to	the logs maintained by
	      the syslogd daemon.  This	is independent of the setting  of  the
	      logfile option (above).  Error messages are by default logged at
	      priority LOG_ERR and successful attempts	to  run	 programs  are
	      logged at	priority LOG_INFO.  (See options syslog_error and sys-
	      log_success to change these levels.)

       syslog_error=xxx
	      (Global) If syslog is enabled (see the syslog option),  then  by
	      default  super logs error	messages using syslog(3) code LOG_ERR.
	      This option changes the code to xxx, where xxx  is  any  of  the
	      usual   syslog(3)	  priority  and/or  facility  codes,  such  as
	      LOG_WARNING or LOG_LOCAL7|LOG_ERR.  The  LOG_xxx	words  can  be
	      separated	 by  whitespace,  dot, and/or ``|'', but of course you
	      must use quotes if whitespace is included.  The  leading	"LOG_"
	      is  optional,  and  the value is case-insensitive.  For example,
	      LOG_LOCAL7|LOG_ERR can alternatively be written  as  local7.err.
	      Super doesn't know what are sensible codes -- it's up to the su-
	      per.tab writer to	choose meaningful values.   For	 instance,  if
	      you put
		   syslog_error="LOG_INFO | LOG_ERR" (bad!)
	      then  you	will get both those values or'd	together and passed to
	      syslog().

       syslog_success=xxx
	      (Global) This option is just like	syslog_error, except  that  it
	      applies  to  successful-execution	messages instead of error mes-
	      sages.  Default: LOG_INFO	.

       Group 3.	 Extra Help Information	for Users.

       info=xxx
	      (Local) The string xxx is	printed	when giving help to users.  It
	      should be	set to a helpful one-line description of the command.

       Group 4.	 Password and Other Restrictions Before	Approval.

       maxlen=[mmm,]nnn
	      (Local|Global) Each argument must	be no more than	mmm characters
	      long (including the terminating null), and the sum length	of all
	      arguments	 must  not  exceed  nnn	 characters.  A	negative value
	      means that no limit is applied.  The defaults for	 mmm  and  nnn
	      are  set	by  the	compile-time manifest constants	MAXLEN1ARG and
	      MAXLENARGS, which	are usually 1000 and  10,000  characters,  re-
	      spectively.

       nargs=[mmm-]nnn
	      (Local|Global) The user is required to enter mmm - nnn arguments
	      to the command.  If just nnn is given, the user must  enter  ex-
	      actly nnn	arguments.  These arguments are	in addition to any ar-
	      guments entered in the command part of the super.tab file.   The
	      default is to allow the user to enter any	number of arguments.

       arg[mmm-]nnn=sss
	      (Local|Global)  This  means  that	the nnn'th or mmm-nnn'th argu-
	      ments must match pattern sss.  (Arguments	are numbered  from 1.)
	      The  pattern  must  be  enclosed in quotes if it contains	white-
	      space.  Note that	this option does not  require  that  there  be
	      mmm-nnn  arguments;  it only says	what those arguments must look
	      like, if entered.	 You can use this option several times on  one
	      line,  with different mmm-nnn values each	time, to apply differ-
	      ent patterns to different	arguments.  If more than  one  pattern
	      applies  to  a  given  argument,	all  of	those patterns must be
	      matched.	An empty pattern ("") is special: it has the effect of
	      unsetting	 (removing)  any  previous  patterns  for the matching
	      [mmm-]nnn.  This can be useful if	you  want  to  change  :global
	      settings,	 instead  of  adding  to  them.	  If  there  are local
	      arg[mmm-]nnn  option(s),	they  completely  replace  all	global
	      arg[mmm-]nnn  values,  even  if  the local mmm-nnn values	do not
	      overlap with the global values.

       owner=xxx
	      (Local|Global) This option specifies that	 the  FullPath	(after
	      asterisk-substitution)  must  be	owned by user (or uid) xxx, or
	      else it won't be executed.

       auth=y|n
	      (Local|Global) If	y, user	authentication is required before  the
	      command  is executed.  The default authentication	method is Unix
	      password authentication.	See also the options  authprompt,  au-
	      thtype,  authuser,  timeout,  and	renewtime, and be sure to read
	      the warning under	timestampbyhost.

       authprompt=message
	      (Local|Global) Specifies the prompt used when authenticating the
	      user  (usually  the default prompt is fine).  Variable substitu-
	      tion is done on the prompt before	printing.

       authtype=type
	      (Local|Global) Specifies the type	of  authentication  used  when
	      auth=y.  The type	can be password	or PAM (if PAM is supported on
	      your system).  The default is password.  If  PAM	authentication
	      is  used,	super uses the service name ``super'' when looking for
	      authentication in	your system PAM	configuration files.

       authuser=username
	      (Local|Global) Specifies the user	whose  authentication  is  re-
	      quired  when  auth=y.  The default is the	password (or other au-
	      thentication) for	the user who invoked super.

       password=y|n
	      (Local|Global) This is a deprecated option; it has been replaced
	      by  the  auth and	authtype options.  Password=y is equivalent to
	      auth=y authtype=password	;  and	Password=n  is	equivalent  to
	      auth=n.

       renewtime=y|n
	      (Global)	If y, the user's timestamp file	is updated to the cur-
	      rent time	whenever an authentication-requiring command  is  exe-
	      cuted.   The  result  is that a user who frequently executes au-
	      thentication-requiring commands won't  need  to  re-authenticate
	      until  more than timeout minutes elapse since the	last such com-
	      mand.  Otherwise,	the user will need to re-authenticate  timeout
	      minutes after last entering the password.	 The default is	n.

       timeout=m
	      (Local|Global)  User  authentication is good for m minutes; that
	      is, the command may be executed without re-authenticating	for  m
	      minutes  after  the  previous  authentication (for any command).
	      After m minutes, user authentication will	be required again  be-
	      fore  the	 command can be	executed.  If timeout is zero or nega-
	      tive, authentication is required every time the command is used.
	      The timestamp for	user usr is recorded in	the file TIMESTAMP_DIR
	      directory	(see timestampbyhost and the FILES section, below).

       timestampbyhost=y|n
	      (Global) If y (default), the timestamp  files  are  given	 names
	      that  are	 unique	 on  each host.	 For instance, jouser@somehost
	      will  be	given  a  timestamp  file  named   TIMESTAMP_DIR/some-
	      host/jouser,  where  TIMESTAMP_DIR  is defined in	the FILES sec-
	      tion.  If	timestmapbyhost=n, the timestamp files are given names
	      that  are	unique to each user, but not unique per	host.  For in-
	      stance, jouser on	any host will be given a timestamp file	 named
	      TIMESTAMP_DIR/jouser.
	      WARNING:	The  hostname  used  is	that from gethostname().  Note
	      that this	is not necessarily  unique  across  internet  domains,
	      since  it	 is  frequently	 not  a	 fully-qualified  domain name.
	      Therefore	you should not share timestamp directories with	 hosts
	      outside the local	domain.	 (Generally such connections don't ex-
	      ist, but one could crossmount the	timestamp directory disk...)

       timestampuid=xxx
	      If a password is required, the time at which it was  entered  is
	      recorded	as  the	mtime of a timestamp file.  The	timestamp file
	      is normally created with owner=root; however, this option	causes
	      it  to  be  created/modified  using uid=xxx (xxx can be either a
	      username or numeric uid).	 This option is	useful when a  network
	      of  hosts	are sharing a cross-mounted timestamp directory.  Note
	      that networks are	typically configured to	not allow root on  one
	      host  to	have  root access to files on another host, which will
	      forbid root on other hosts from creating the timestamp file  un-
	      less  it's  world-writable.   This option	allows you to have the
	      file created/opened under	another	uid that does have  cross-host
	      access, such as the uid of a system manager.  Default: timestam-
	      puid=0.

       checkvar=name[,...]
	      (Local) Each name	in the comma-separated	list  is  a  super.tab
	      variable	which the user must enter at a prompt from super.  For
	      example, you might have a	super shutdown command which halts the
	      computer.	  If  you  execute this	on the wrong host there	may be
	      some very	annoyed	users!	So, you	can include checkvar=HOST, and
	      the user will have to type the correct hostname in response to a
	      prompt from super.

       Group 5.	 Modifications to Environment Before Executing Command.

       uid=xxx
	      (Local) Sets the real uid	to xxx just before executing the  com-
	      mand.  If	option euid isn't used,	also sets the effective	uid to
	      xxx.  The	uid xxx	is first tried as a login name and then	 as  a
	      number.  If the options uid=xxx and u+g=yyy (see below) are used
	      together,	then the u+g option only sets the  group id,  and  not
	      the user id.

       euid=xxx
	      (Local)  Sets the	effective uid to xxx just before executing the
	      command.	The uid	xxx is first tried as a	login name and then as
	      a	number.

       gid=yyy
	      (Local)  Sets the	real gid to yyy	just before executing the com-
	      mand.  If	option egid isn't used,	also sets the effective	gid to
	      yyy.   The  gid yyy is first tried as a group name and then as a
	      number.

       egid=yyy
	      (Local) Sets the effective gid to	yyy just before	executing  the
	      command.	The gid	yyy is first tried as a	group name and then as
	      a	number.

       u+g=zzz
	      (Local) Sets the real uid	to zzz,	the real gid  to  zzz's	 login
	      gid,  and	 the  supplementary groups list	to zzz's supplementary
	      groups just before executing the command.	 If  the  euid	and/or
	      egid  option aren't given, the effective uid and/or gid are also
	      set.  The	options	u+g and	gid=yyy	conflict with each other,  and
	      may not be used together.

       groups=name[,...]
	      (Local|Global)  By default, the user's supplementary groups list
	      is deleted before	executing a command (unless the	option u+g  is
	      used).  This option instead sets the group list to name[,...]

       addgroups=name[,...]
	      (Local|Global) This option adds the listed groups	to the supple-
	      mentary groups list.  Since the default is to provide  an	 empty
	      supplementary  groups list, this option usually has the same ef-
	      fect as the  plain  groups  option.   However,  if  the  options
	      u+g=foo  addgroups=a,b,c are used, then the supplementary	groups
	      list is composed of user foo's supplementary groups plus	a,  b,
	      and c.

       argv0=name
	      (Local) Execute the command will execute with its	first argument
	      (that is,	the argument conventionally denoted as	argv[0]),  set
	      to name.	As a convenient	shorthand, the value <path> (the angle
	      brackets are literally part of the name) means to	use the	 Full-
	      Path  specified  in  the super.tab file.	By default, argv[0] is
	      set to Cmd, the name of the super	command	invoked	by  the	 user,
	      regardless of the	actual path being invoked.  However, some pro-
	      grams will not run properly  unless  argv[0]  has	 a  particular
	      value.   For example, suppose you	want to	permit users to	safely
	      mount zip	disks, and you use something like:
		   zipmount "/etc/mount	-o nosuid /dev/xz10  /zip"
	      This command will	fail if	/etc/mount requires that it be invoked
	      with argv[0] set to [.../]mount, because super will use the name
	      zipmount.	 However, you can put argv0=<path> into	your super.tab
	      file, and	then the mount command will work properly.

       env=name[,...]
	      (Global|Local) Each name in the comma-separated list is an envi-
	      ronment variable which should not	be  deleted  before  executing
	      the Cmd; these variables are in addition to the normal variables
	      created or passed	by super  (TERM,  IFS,	PATH,  USER,  LOGNAME,
	      HOME, ORIG_USER, ORIG_LOGNAME, ORIG_HOME,	LINES, COLUMNS,	SUPER-
	      CMD).  Be	careful	here; environment variables can	 sometimes  be
	      abused  to  create  security  holes.  If you use the option more
	      than once, the later instance overrides the earlier one, instead
	      of  adding  to  it.   Similarly, using it	as a local option com-
	      pletely overrides	any global setting.

       maxenvlen=nnn
	      (Global|Local) Specifies the maximum length  of  an  environment
	      variable	definition  (including	name,  equal  sign, value, and
	      trailing null character).	 The default is	given by the  compile-
	      time  manifest  constant	MAXENVLEN, usually 1000	characters.  A
	      negative value means no limit.

       cd=dir
	      (Local|Global) Just before executing the command,	super  changes
	      the working directory to dir.

       setenv=var=xxx
	      (Local|Global)  The  environment variable	var is defined to have
	      the value	xxx, and is passed on when executing the Cmd.  You can
	      add several environment variable definitions by using the	option
	      more than	once.

       fd=n[,...]
	      (Local) Each file	 descriptor  n	in  the	 comma-separated  list
	      should  not  be closed before executing the Cmd.	These descrip-
	      tors are added to	the usual set of descriptors kept open,	namely
	      0, 1, 2.

       nice=n
	      (Local|Global)  changes  the ``nice'' value of the executed com-
	      mand by an amount	n from the default  level.   (Positive	incre-
	      ments  reduce  the  command's  priority; negative	increments in-
	      crease it.)

       umask=nnn
	      (Local|Global) sets the umask of any executed command to	n.   A
	      leading  0x or 0X	in nnn means a hexadecimal value; otherwise, a
	      leading 0	means octal; otherwise it's decimal.

       Group 6.	 Other Options

       print=message
	      (Local) If the rest of the line is matched,  then	 super	prints
	      the specified message just before	executing the command.

       die=message
	      (Local)  If  the	rest  of  the line is matched, then super does
	      variable-substitution on the specified message  message,	prints
	      it,  and exits.  This lets you conveniently set up some ``stop''
	      conditions, and use the die option to prevent super from looking
	      at  any line past	the stop conditions.  Otherwise, you'd have to
	      individually attach the stop conditions to every control line.

Include	Files
       A super.tab file	can include other files	by means of an entry like
	      :include filename	[ owner=xxx ] [	group=yyy  ]
       or
	      :optinclude file [ owner=xxx ] [ group=yyy  ]
       If the file isn't an absolute path, it is taken to be relative  to  the
       directory  containing  the super.tab file.  Include files may be	nested
       up to the system	limit on the number of	simultaneously-open  file  de-
       scriptors.

       The owner=xxx option specifies that the file must be owned by user xxx;
       the group=yyy options specifies that the	file must belong to group yyy.
       If  group=yyy is	specified, then	the file can be	group-writable;	by de-
       fault, the file must be writable	only by	owner.	This can be useful for
       a collection of accounts	that are operated together as part of a	single
       project -- the several of accounts can share .supertab  files  by  :in-
       clude-ing  files	 belonging  to	the trusted user xxx and/or group yyy.
       Notes:

	      1.  The regular root-owned  super.tab  file  can	also  use  the
	      owner= or	group= constructs, but it's not	a good idea.  Don't do
	      it.

	      2.  Beware of the	transitive nature  of  this  trust:  the  file
	      owned  by	 xxx  can  in turn include a file owned	by yet another
	      user.  You might wind up trusting	a user you  didn't  intend  to
	      trust!

       The difference between :include and :optinclude is that the former gen-
       erates an error if the named file doesn't  exist,  whereas  the	latter
       (optional-include) silently ignores files that don't exist.

       WARNING:	You should use :optinclude with	great caution, and be sure not
       to depend on that file being present.  It is easy to imagine a scenario
       in which	an administrator carelessly changes an entry so	that the wrong
       permission is granted if	an :optinclude'd file was missing.

FILES
       /usr/local/etc/super.tab
	      The location of the super.tab file on your system.

       /usr/local/etc/super.init
	      The location of the super.init file on your system.

       /usr/local/var/super/timestamps/username
	      Default location of the file whose mtime is used	as  the	 time-
	      stamp for	the last time the user entered his or her password for
	      password-requiring commands.  Check your	installation  for  the
	      directory	used on	your system.

EXAMPLES
       Example 1.  The control line

		   doit	/usr/local/bin/doit		   \
			     me				   \
			     you@{h1,h32}		   \
			     ja.*:ok_j			   \
			     :goodguys

	      allows /usr/local/bin/doit to be run setuid-root by
		   o user me on	any host,
		   o user you on hosts h1 and h32;
		   o any users named ja.*  in group ok_j;
		   o and anybody in group goodguys.

       Example 2.  The pair of control lines

		   doit	/usr/local/bin/doit		   \
			     u+g=smith env=TZ,TAPE	   \
			     password=y	timeout=0	   \
			     jo@PublicWorkstation

		   doit	/usr/local/bin/doit		   \
			     u+g=smith env=TZ,TAPE	   \
			     jo

	      allows  user  jo	to  run	 /usr/local/bin/doit with uid =	smith,
	      gid = smith's login gid, and keeping the	environment  variables
	      TZ  and  TAPE in addition	to the standard	set.  If user jo is at
	      PublicWorkstation, the first entry will  match,  requiring  jo's
	      password	every  time the	command	is used; otherwise, super will
	      match at the second entry, and no	password is needed to run  the
	      command.

       Example	3.   Here is an	entry restricting CD-ROM mounting on different
	      hosts: tas is the	only user who may mount	CD's on	elgar; anybody
	      in  group	xyz may	mount CD's on alpha or delta; and anybody on a
	      host in the netgroup india may mount a CD	on  the	 india	hosts.
	      However, user jo may never run cdmount, regardless of his	or her
	      group or host (assuming that there is no overriding global  pat-
	      tern that	permits	jo to use the command).	 Note that shell-style
	      patterns are used, not regex-style patterns.

		   cdmount /usr/local/bin/cdmount	   \
			     tas@elgar			   \
			     :xyz@{alpha,delta}		   \
			     *@+india			   \
			     !jo

SEE ALSO
       super(1).

				     local			      SUPER(5)

NAME | DESCRIPTION | The CmdPat Field | The FullPath Field | Permitted Users | Permitted Times | Global Conditions | Conditionally-included Control Lines | Variables | Options | Include Files | FILES | EXAMPLES | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=super&sektion=5&manpath=FreeBSD+12.0-RELEASE+and+Ports>

home | help