swacl man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

swacl(8)							      swacl(8)

NAME
       swacl  -	 view  or modify the Access Control Lists (ACLs) which protect
       software products

SYNOPSIS
       swacl -l level [-D acl_entry| -F	 acl_file|  -M	acl_entry]  [-f	 soft‐
	      ware_file]  [-t  target_file] [-x option=value] [-X option_file]
	      [software_selections][ target_selections]

STANDARDS
       Interfaces documented on this reference page conform to industry	 stan‐
       dards as follows:

       POSIX 1387.2, XDSA

       Refer  to  the  standards(5)  reference page for more information about
       industry standards and associated tags.

DESCRIPTION
       The swacl command displays or modifies the Access Control Lists	(ACLs)
       which:

	      ·	 Protect  the  specified  target_selections  (hosts,  software
		 depots or root filesystems).

	      ·	 Protect the specified	software_selections  on	 each  of  the
		 specified target_selections (software depots only).

       All  root filesystems, software depots, and products in software depots
       are protected by ACLs.  The SWMGR commands permit or  prevent  specific
       operations based on whether the ACLs on these objects permit the opera‐
       tion.  The swacl command is used to view, edit, and manage these	 ACLs.
       The  ACL	 must  exist and the user must have the appropriate permission
       (granted by the ACL itself) in order to modify it.

       ACLs offer a greater degree of selectivity than standard	 file  permis‐
       sions.	ACLs  allow  an	 object's owner (i.e. the user who created the
       object) or the local superuser to define specific read, write, or  mod‐
       ify  permissions	 to  a specific list of users, groups, or combinations
       thereof.

       Some operations allowed by ACLs are run	as  local  superuser.  Because
       files  are  loaded  and	scripts	 are run as superuser, granting a user
       write permission on a root filesystem or insert permission  on  a  host
       effectively gives that user superuser privileges.

   Protected Objects
       The following objects are protected by ACLs:

	      ·	 Each host system on which software is being managed by SWMGR,

	      ·	 Each root filesystem on a host (including alternate roots),

	      ·	 Each software depot on a host,

	      ·	 Each software product contained within a depot.

   Options
       If  the	-D,  -F,  or  -M  option  is  not  specified, swacl prints the
       requested ACL(s) to the standard output.

       The swacl command supports the following options:

	      -D acl_entry   Deletes an existing entry from the ACL associated
			     with  the	specified object(s).  For this option,
			     the permission field of  the  ACL	entry  is  not
			     required.	Multiple -D options can be specified.

	      -f software_file
			     Read  the	list of software_selections from soft‐
			     ware_file instead of (or in addition to) the com‐
			     mand line.

	      -F acl_file    Assigns  the  ACL	contained  in  acl_file to the
			     object.  All existing  entries  are  removed  and
			     replaced  by  the	entries in the file.  Only the
			     ACL's entries are replaced; none of the  informa‐
			     tion contained in the comment portion (lines with
			     the prefix ``#'') of an ACL listing  is  modified
			     with  this	 option.   The acl_file is usually the
			     edited output of a swacl list operation.

			     If the replacement ACL contains no syntax	errors
			     and  the  user  has control permission on the ACL
			     (or is the local superuser), the replacement suc‐
			     ceeds.

	      -l level	     Defines which level of SWMGR ACLs to view/modify.

			     The  supported  levels  of depot, host, root, and
			     product objects that can be protected are:

			     depot	 View/modify the  ACL  protecting  the
					 software  depot(s)  identified by the
					 target_selections.

			     host	 View/modify the  ACL  protecting  the
					 host system(s) identified by the tar‐
					 get_selections.

			     root	 View/modify the  ACL  protecting  the
					 root  filesystem(s) identified by the
					 target_selections.

			     product	 View/modify the  ACL  protecting  the
					 software  product  identified	by the
					 software_selection.  Applies only  to
					 products  in  depots,	not  installed
					 products in roots.

			     The supported levels of templates are:

			     global_soc_template
					 View/modify the template ACL used  to
					 initialize the ACL(s) of future soft‐
					 ware depot(s) or  root	 filesystem(s)
					 added	to  the	 host(s) identified by
					 the target_selections.	 Additionally,
					 swacl can be used to set templates to
					 be used when new ACLs are created.

			     global_product_template
					 View/modify the template ACL used  to
					 initialize    the    product_template
					 ACL(s) of  future  software  depot(s)
					 added	to  the	 host(s) identified by
					 the target_selections.

			     product_template
					 View/modify the template ACL used  to
					 initialize the ACL(s) of future prod‐
					 uct(s) added to the software depot(s)
					 identified by the target_selections.

	      -M acl_entry   Adds  a  new ACL entry or changes the permissions
			     of an existing entry.  Multiple -M options can be
			     specified.

	      -t target_file Read  the	list  of  target_selections  from file
			     instead of (or in addition to) the command line.

	      -x option=value
			     Set the session option to value and override  the
			     default   value  (or  a  value  in	 an  alternate
			     option_file specified with the -X option).	  Mul‐
			     tiple -x options can be specified.

	      -X option_file Read  the	session	 options  and  behaviors  from
			     option_file.

       Only one of the -D, -F, or -M options can be specified for  an  invoca‐
       tion of swacl.

   Operands
       Most  SWMGR  commands  support two types of operands: followed by These
       operands are separated by the "@" (at) character. This  syntax  implies
       that the command operates on "software selections at targets".

   Software Selections
       The  swacl  command  supports  the  following  syntax  for  each	 soft‐
       ware_selection:

	      product[,version]

	      ·	     The =  (equals)  relational  operator  lets  you  specify
		     selections with the following shell wildcard and pattern-
		     matching notations:

		     [ ], *, ?

	      ·	     The \* software specification selects all products in the
		     depot when used with -l product.

	      The version component usually has the following form:

		     [,r <op> revision][,a <op> arch][,v <op> vendor]
		     [,c <op> category]

		     ·	 The  <op>  (relational	 operator) component can be of
			 the form:

			    ==, >=, <=, <, >, or !=

			 which performs individual  comparisons	 on  dot-sepa‐
			 rated fields.

			 For example, r>=B.10.00 chooses all revisions greater
			 than or equal to B.10.00.  The system	compares  each
			 dot-separated	field  to find matches. Shell patterns
			 are not allowed with these operators.

		     ·	 The = (equals) relational operator lets  you  specify
			 selections with the shell wildcard and pattern-match‐
			 ing notations:

			    [ ], *, ?, !

			 For example, the expression  r=1[01].*	  returns  any
			 revision in version 10 or version 11.

		     ·	 All version components are repeatable within a single
			 specification (e.g.  r>=A.12, r<A.20).	  If  multiple
			 components  are  used,	 the  selection must match all
			 components.

		     ·	 Fully qualified software specs include	 the  r=,  a=,
			 and  v= version components even if they contain empty
			 strings.

		     ·	 No space or tab characters are allowed in a  software
			 selection.

		     ·	 The software can take the place of the version compo‐
			 nent. It has the form:

			    [instance_id]

			 within the context of an exported catalog,  where  is
			 an  integer  that  distinguishes versions of products
			 and bundles with the same tag.

   Target Selections
       The SWMGR commands support this syntax for each target_selection.

	      [host][:][/directory]

       The : (colon) is required if both a host and directory are specified.

EXTERNAL INFLUENCES
   Defaults Options
       In addition to the standard options, several SWMGR behaviors and policy
       options can be changed by editing the default values found in:

	      /var/adm/sw/defaults	    the system-wide default values,

	      $HOME/.swdefaults		    the user-specific default values.

       Values must be specified in the defaults file using this syntax:

	      [command_name.]option=value

       The optional prefix denotes one of the SWMGR commands. Using the prefix
       limits the change in the default value to that command.	If  you	 leave
       the prefix off, the change applies to all commands.

       You  can also override default values from the command line with the -x
       or -X options:

       The following section lists all of the keywords supported by the	 swacl
       command. If a default value exists, it is listed after the "=".

	      distribution_target_directory=/var/spool/sw
			Defines the default location of the target depot.

	      installed_software_catalog=products
			Defines	 the  directory path where the Installed Prod‐
			ucts Database (IPD) is stored. When set to an absolute
			path,  this  option  defines  the location of the IPD.
			When this option contains a relative path,  the	 SWMGR
			controller  appends the value to /var/adm/sw to deter‐
			mine the path to the IPD.  For alternate  roots,  this
			path  is  resolved  relative  to  the  location of the
			alternate root.	 This option  does  not	 affect	 where
			software is installed, only the IPD location.

	      level=	Defines	 the  level of SWMGR ACLS to view/modify.  The
			supported levels  are:	host,  depot,  root,  product,
			product_template, global_soc_template, or global_prod‐
			uct_template.

			See the discussion of the -l  option  above  for  more
			information.

	      rpc_binding_info=ncacn_ip_tcp:[2121] ncadg_ip_udp:[2121]
			Defines	 the  protocol	sequence(s) and endpoint(s) on
			which the daemon listens and which the other  commands
			use  to	 contact  the daemon.  If the connection fails
			for one protocol  sequence,  the  next	is  attempted.
			SWMGR  supports both the tcp (ncacn_ip_tcp:[2121]) and
			udp (ncadg_ip_udp:[2121]) protocol  sequence  on  most
			platforms.

	      rpc_timeout=5
			Relative  length  of the communications timeout.  This
			is a value in the range from 0 to 9 and is interpreted
			by  the DCE RPC.  Higher values mean longer times; you
			may need a higher value for a slow  or	busy  network.
			Lower  values will give faster recognition on attempts
			to contact hosts that are not up, or are  not  running
			swagentd.   Each  value is approximately twice as long
			as the preceding value.	 A value of 5 is about 30 sec‐
			onds  for  the	ncadg_ip_udp  protocol sequence.  This
			option may not have any noticeable impact  when	 using
			the ncacn_ip_tcp protocol sequence.

	      select_local=true
			If  no	target_selections  are	specified,  select the
			default target_directory of the local host as the tar‐
			get_selection for the command.

	      software= Defines	 the default software_selections.  There is no
			supplied default.  If there is more than one  software
			selection, they must be separated by spaces.

	      targets=	Defines	 the  default  target_selections.  There is no
			supplied default (see select_local above).   If	 there
			is  more than one target selection, they must be sepa‐
			rated by spaces.

	      verbose=1 Controls the verbosity of the output (stdout). A value
			of
			0   disables  output  to  stdout.   (Error and warning
			    messages are always written to stderr).
			1   enables verbose messaging to stdout.

   Environment Variables
       SWMGR programs are affected  by	external  environment  variables,  set
       environment  variables  for  use	 by the control scripts, and use other
       environment variables that affect command behavior.

       The external environment variable that affects the swacl command is:

	      LANG	Determines the language in  which  messages  are  dis‐
			played.	  If  LANG  is	not specified or is set to the
			empty string, a default value of C is used.   See  the
			lang(5)	 man page by typing man 5 lang for more infor‐
			mation.

			Note: The language in which the SWMGR agent and daemon
			log  messages  are displayed is set by the system con‐
			figuration  variable  script,	/etc/rc.config.d/LANG.
			For  example,  /etc/rc.config.d/LANG,  must  be set to
			LANG=ja_JP.SJIS or LANG=ja_JP.eucJP to make the	 agent
			and daemon log messages display in Japanese.

	      LC_ALL	Determines  the locale to be used to override any val‐
			ues for locale categories specified by the settings of
			LANG or any environment variables beginning with LC_.

	      LC_CTYPE	Determines the interpretation of sequences of bytes of
			text data as characters (e.g., single-versus multibyte
			characters in values for vendor-defined attributes).

	      LC_MESSAGES
			Determines  the	 language  in which messages should be
			written.

	      LC_TIME	Determines  the	 format	 of  dates  (create_date   and
			mod_date) when displayed by swlist.  Used by all util‐
			ities when displaying dates and times in stdout,  log‐
			ging.

	      TZ	Determines the time zone for use when displaying dates
			and times.

OPERATION
       Each entry in an ACL has the following form:

	      entry_type[:key]:permissions

	      For example: user:steve@daria:crwit

       An ACL can contain multiple entries.

   List Output Format
       The output of a list operation is in the following format:

		 # swacl   Object_type	   Access Control List
		 #
		 # For	   depot|host:[host]:[/directory]
		 #
		 # Date:   date_stamp
		 #
		 # Object Ownership:  User=  user_name
		 #		      Group= group_name
		 #		      Realm= host_name
		 #
		 # default_realm = host_name
		 entry_type:[key:]permissions
		 entry_type:[key:]permissions
		 entry_type:[key:]permissions

       This output can be saved into a file, modified, and then used as	 input
       to a swacl modify operation (see the -F option above).

   Object Ownership
       An  owner is also associated with every SWMGR object, as defined by the
       user name, group and hostname.  The owner is the user who  created  the
       object.	 When  using  swacl  to view an ACL, the owner is printed as a
       comment in the header.

   Default Realm
       An ACL defines a default realm for an object.  The realm	 is  currently
       defined	as  the	 name  of the host system on which the object resides.
       When using swacl to view an ACL, the default realm is printed as a com‐
       ment in the header.

   Entry Types
       The following entry_types are supported:

	      any_other	     Permissions for all other users and hosts that do
			     not match a  more	specific  entry	 in  the  ACL.
			     (Example: any_other:-r--t.)

	      group	     Permissions  for a named group.  This type of ACL
			     entry must include a  key	that  identifies  that
			     group.   The format can be: group:group_name:per‐
			     missions	or   group:group_name@hostname:permis‐
			     sions.  (Example: group:adm:crwit.)

	      host	     Permissions for an SWMGR agent from the specified
			     host system.  SWMGR agents require product	 level
			     read   access   via  either  a  host,  other,  or
			     any_other entry type in order to copy or  install
			     products  from  depots.   This  type of ACL entry
			     must include a key containing a hostname or  num‐
			     ber  (in  Internet	 dot  notation)	 of  a system.
			     (Example: host:daria@unx.dec.com:-r--t.)

	      object_owner   Permissions for the object's owner,  whose	 iden‐
			     tity  is listed in the comment header.  (Example:
			     object_owner:crwit.)

	      object_group   Permissions for members of	 the  object's	group,
			     whose  identity  is listed in the comment header.
			     (Example: object_group:crwit.)

	      other	     Permissions for  others  who  are	not  otherwise
			     named  by a more specific entry type.  The format
			     for other can be: other:permissions for others on
			     the  local	 host (only one such entry allowed) or
			     other:@hostname:permissions for others at	remote
			     hosts  (Only  one	such  entry  per  remote  host
			     allowed).	(Example: other:@daria:-r--t.)

	      user	     Permissions for a named user.  This type  of  ACL
			     entry  must  include  a  key that identifies that
			     user.    The   format   for    user    can	   be:
			     user:user_name:permissions			    or
			     user:user_name@hostname:permissions.    (Example:
			     user:rml:crwit.)

   Keys
       Expressions (patterns) are not permitted in keys.

       A  key  is  required  for  user,	 group and host entry types.  A key is
       optional for other entry types, and specifies the hostname to which the
       entry  applies.	Only one other entry type may exist without a key, and
       this entry applies to users at the default realm (host) of the ACL.

       A hostname in a key will be listed in its Internet address format  (dot
       notation)  if  swacl  cannot resolve the address using the local lookup
       mechanism (DNS, NIS, or /etc/hosts).  A hostname within	an  ACL	 entry
       must  be resolvable when used with the -D and -M options.  Unresolvable
       hostname values are accepted in files provided with the -F option.

   Permissions
       Permissions are represented as the single character abbreviations indi‐
       cated  below.  Some permissions either apply only to, or have different
       meaning for, certain types of objects, as detailed below.  The  follow‐
       ing permissions may be granted:

	      r ead	  Grants  permission  to  read	the  object.  On host,
			  depot,  or  root  objects,  read  permission	allows
			  swlist  operations.  On products within depots, read
			  permission allows product files to be	 installed  or
			  copied with swinstallor

	      w rite	  Grants permission to modify the object itself.

			  · On a root object (e.g. installed root filesystem),
			  this also grants permission to modify	 the  products
			  installed (contained) within it.

			  · On a depot object, it does not grant permission to
			  modify  the  products	 contained  within  it.	 Write
			  access on products is required to modify products in
			  a depot.

			  · On a host container, write permission grants  per‐
			  mission  to  unregister  depots.   It does not grant
			  permission to modify the depots or  roots  contained
			  within it.

					·
			  On  a	 host  object,	grants	permission  to	create
			  (insert) a new software  depot  or  root  filesystem
			  object,  and	to  register  roots  and depots.  On a
			  depot object, grants permission to create (insert) a
			  new product object into the depot.

	      c ontrol	  Grants permission to modify the ACL using swacl.

	      t est	  Grants  permission  to  perform access checks and to
			  list the ACL.

	      a ll	  A wildcard which grants all  of  the	above  permis‐
			  sions.  It is expanded by swacl to crwit.

RETURN VALUE
       The swacl command returns:

	      0	  The  software_selections  and/or target_selections were suc‐
		  cessfully displayed or modified.
	      1	  The display/modify operation	failed	on  all	 target_selec‐
		  tions.
	      2	  The  modify/modify  operation	 failed	 on some target_selec‐
		  tions.

DIAGNOSTICS
       The swacl command writes to stdout, stderr, and to the daemon logfile.

   Standard Output
       The swacl command prints	 ACL  information  to  stdout  when  the  user
       requests an ACL listing.

   Standard Error
       The  swacl command writes messages for all WARNING and ERROR conditions
       to stderr.  A report that the software_selections do not exist is  also
       given if the user has no access permissions to the object.

   Logging
       The  swacl  command  does not log summary events.  It logs events about
       each ACL which is modified to the swagentd logfile associated with each
       target_selection.

EXAMPLES
       To  list	 the  ACLs  for	 the  COBOL  and  FORTRAN  products  in	 depot
       /var/spool/swtest:

	      swacl -l product COBOL FORTRAN @ /var/spool/swtest

       The ACL listed to the standard output is similar to this example ACL:

		 #
		 # swacl Product Access Control Lists
		 #
		 # For depot: daria:/var/spool/swtest
		 #
		 # Date: Wed May 26 11:14:31 1993
		 #
		 #
		 # For product: COBOL,r=3.2
		 #
		 #
		 # Object Ownership: User= patv
		 # Group= swadm
		 # Realm= daria.unx.dec.com
		 #
		 # default_realm=daria.unx.dec.com
		 object_owner:crwit
		 group:swadm:crwit
		 any_other:-r--t
		 #
		 # For product: FORTRAN,r=9.4
		 #
		 #
		 # Object Ownership: User= patv
		 # Group= swadm
		 # Realm= daria.unx.dec.com
		 #
		 # default_realm=daria.unx.dec.com
		 object_owner:crwit
		 user:rob@ lehi.unx.dec.com:-r--t
		 user:barb:-r--t
		 user:ramon:-r--t
		 group:swadm:crwit
		 other:-r--t
		 host:lehi.unx.dec.com:-r--t

       To list the product template ACL on host daria:

	      swacl -l global_product_template	@ daria

       To list the host ACL on the local system:

	      swacl -l host

       To read, edit, then  replace  the  ACL  protecting  the	default	 depot
       /var/spool/sw:

	      swacl -l depot > new_acl_file
	      vi new_acl_file
	      swacl -l depot -F new_acl_file

       To  add	an  entry  for user george on host daria to the ACL protecting
       COBOL in the default depot at host lehi:

	      swacl -l product -M user:george@daria:crwit COBOL @ lehi:

       To deny all access  to  the  users  steve  and  george  for  the	 depot
       /var/spool/sw at host daria:

	      swacl -l depot -M user:steve:- -M user:george:-
	      @ daria:/var/spool/sw

       To  delete entries for local user rick from all products in the default
       local depot:

	      swacl -l product -D user:rick \*

WARNINGS
       It is possible to edit an ACL in such a way as to render it  inaccessi‐
       ble.  Be careful not to remove all control permissions on an ACL.  As a
       safeguard, the local super-user may always edit SWMGR ACLs,  regardless
       of permissions

       Operations are allowed by ACLs using local superuser. Because files are
       loaded and scripts are run as superuser, granting write permission on a
       root  filesystem	 or insert permission on a host effectively gives that
       user superuser privileges.

       swacl is not a general purpose ACL editor, it works only on  ACLs  pro‐
       tecting SWMGR objects.

FILES
       $HOME/.swdefaults
	      Contains	the user-specific default values for some or all SWMGR
	      options.

       /usr/lib/sw/sys.defaults
	      Contains the master list of current SWMGR	 options  (with	 their
	      default values).

       /var/adm/sw/
	      The  directory  which contains all of the configurable (and non-
	      configurable) data  for  SWMGR.	This  directory	 is  also  the
	      default location of logfiles.

       /var/adm/sw/defaults
	      Contains	the  active system-wide default values for some or all
	      SWMGR options.

       /var/adm/sw/products/
	      The Installed Products Database (IPD), a catalog of all products
	      installed on a system.

       /var/adm/sw/security/
	      The  directory  which  contains ACLs for the system itself, tem‐
	      plate ACLS, and the secrets file	used  to  authenticate	remote
	      requests.

       /var/spool/sw/
	      The default location of a source and target software depot.

SEE ALSO
       sd(4),  sd(5), swagentd(8), swask(8), swconfig(8), swgettools(8), swin‐
       stall(8), swlist(8), swmodify(8), swpackage(8), swpackage(4), swreg(8),
       swremove(8), swverify(8),

       Also,  refer  to the Managing Tru64 UNIX Software With the SysMan Soft‐
       ware Manager reference manual.

								      swacl(8)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net