Current Supported Releases: Sablime^® v6.0 & v5.2

NAME
     sbcsproj - set-UID interface for SBCS commands

SYNOPSIS
     sbcsproj [-s] sbcs-command

DESCRIPTION
     sbcsproj is a standard-C source template that can be used by
     the SBCS administrator to compile a secure set-UID interface
     to the SBCS commands for a multi-user project.  Each project
     requires its own sbcsproj interface.

     The sbcsproj interface provides three basic services:
          1.set-UID functionality;
          2.correct PATH setting to find the SBCS commands;
          3.setting of the SBCSPROJ project environment variable used by SBCS commands.

     When s-files have to be accessed and modified by  more  than
     one  user,  the  ownerships  and permissions of the s-files,
     theirs directories, and the SBCS commands has to be modified
     to properly use the UNIX system permission features.

     A frequent approach is simply to  ignore  security  concerns
     and  open up the permissions on the s-files and their direc-
     tories to a larger set of people than is strictly required.

     The sbcsproj interface gives the  SBCS  administrator  (adm)
     control over s-file security while not changing the modes of
     the SBCS commands themselves and preserving users' access to
     all the commands and and all their options.

     sbcsproj.c is a standard-C program source that contains  two
     lines that the adm special user must customize.
          static char *sbcsbin = "/tools/sbcs/v1.2/i4864/bin";
          static char *sbcsproj = "/home4/mozart/sbcs12/etc/sbcsenv";
     The variable sbcsbin should be set to the full path  of  the
     directory  containing  the  SBCS  executables (nadmin, ncdc,
     ...).  The variable sbcsproj should be set to the full  path
     of  the  SBCS project environment file (see SBCSPROJ below).
     If no common project environment is needed, the file can  be
     empty,  or  the  sbcsproj variable can be set to NULL or the
     empty string "".  Called without  arguments,  sbcsproj  will
     simply echo these two values.

     Once copied, edited and compiled, the sbcsproj program  must
     be  installed in a place where it is accessed by all project
     members.  This is usually a different place from  where  the
     SBCS commands are located.

     The UNIX environment described below  is  also  outlined  in
     nadmin(1) - MULTI USER ACCESS.

SBCS Release 1.2    Last change: 1 April 1994                   1

     1.   All project members belong  to  a  common  UNIX  system
          group, for example proj;

     2.   adm and proj are the owner and group owner  of  the  s-
          files  and  s-files  have permission modes r--r----- or
          octal 440;

     3.   adm and proj are the  owner  and  group  owner  of  all
          directories  containing  s-files and the directory per-
          missions are rwxr-x--- or octal 750;

     In this context sbcsproj should be owned by adm and proj and
     have  permission modes rwsr-x--- or octal 4750.  This can be
     relaxed, but unless other precautions are taken to limit who
     can run sbcsproj, security will not be achieved.

     Project members run the SBCS commands by calling on sbcsproj
     to run the commands for them.  sbcsproj knows where the SBCS
     commands are, which ones should be run  set-UID,  and  which
     ones should not.  Since it is itself a set-UID program owned
     by adm, it simply reverts to the user's real UID to run com-
     mands  that  should not run with adm permissions.  For exam-
     ple,
          sbcsproj nadmin -i /etc/passwd $projArea/s.pass
     will locate and run nadmin, but not in set-UID mode, because
     the  editing  features  of  nadmin are reserved for adm. adm
     owns the files and the directories anyway and  thus  doesn't
     need  new  set-UID  permissions.   A regular member of proj,
     trying to use nadmin to change an s-file flag, for  example,
     will get a UNIX permission error.  The command
          sbcsproj nget -e $projArea/s.pass
     will locate and run nget in set-UID mode to create or update
     the  p-file in $projArea. nget knows enough to revert to the
     user's real UID to create the g-file in the .  (dot)  direc-
     tory.  Similar comments apply to other SBCS commands.

     The command lines can be simplified by using  shell  aliases
     or  other  methods.   For  example, in ksh(1), the following
     aliases could be defined and used by project members to make
     the sbcsproj interface nearly invisible.
          alias -x nadmin="sbcsproj nadmin"
          alias -x nget="sbcsproj nget"
          ...
     A second method would have the adm special user  create  one
     line scripts, customizing the SBCS commands for one project,
          projadmin --> sbcsproj nadmin "$@"
          projget   --> sbcsproj nget "$@"
          ...
     and placing them in the sbcsproj bin where proj members  can
     find them.

SBCS Release 1.2    Last change: 1 April 1994                   2

     Either way, call to get is resolved into a call to  sbcsproj
     nget and this in turn becomes a call the right nget with the
     right permissions  to  access  the  s-files  and  the  right
     SBCSPROJ in the environment.

     Not all the SBCS commands need to be run  through  sbcsproj,
     but  those  that  can modify an s-file or p-file must.  This
     also  means  that  not  all  commands  need  to  know  about
     SBCSPROJ,  only  those that modify s- or p-files.  Therefore
     sbcsenv variables set by SBCSPROJ are best limited to  those
     that  determine  how  s-  and p-files are modified:  locking
     scheme, branch policy, editing policy, etc...

     A command that does not use sbcsproj must have  enough  per-
     missions on its own to read the s-files when run by a member
     of group proj.  This helps determine the necessary ownership
     and permissions of s-files and their directories.

OPTION
     -s   Silent mode. Do not display messages or warnings,  only
          actual errors.

ENVIRONMENT
     The SBCS environment (sbcsenv) is a collection of name-value
     pairs  that  are  recognized by SBCS commands and are set by
     the user to influence default  command  behavior.   When  an
     SBCS  command  starts,  it  looks  for  SBCSPROJ in the UNIX
     environment. If that variable is not set or is null,  it  is
     ignored.   Otherwise it is expected to be the name of a file
     containing sbcsenv variable definitions.  Commands then look
     for  the  SBCSENV environment variable.  If that variable is
     set and is null, it is ignored.  If it is  set  but  is  not
     null,  it  is  expected  to be the name of a file containing
     sbcsenv variable definitions.  If SBCSENV is  not  set  (not
     defined),  commands  perform a standard search for a default
     .sbcsenv file, first in the current directory, then  up  the
     chain  of  parent  directories. The first one found, if any,
     terminates  the  search.   The  root  directory  /  is   not
     searched.  Variables defined by SBCSPROJ cannot be redefined
     by SBCSENV or a default

     The SBCSPROJ file is the right place to store sbcsenv values
     that  must be shared by all project members. If they use the
     sbcsproj interface, the SBCSPROJ variable will be  automati-
     cally  set  for  them.  Variables that should be defined for
     all  members  include  those  defining  the  s-file  locking
     scheme,  the  branching  policy, etc...  These are up to the
     SBCS administrator to determine.  Commands that can success-
     fully  bypass  sbcsproj  only have read permission on the s-
     files  and  there  is  usually  no  reason  to  limit  their
     behavior.   The  fact  that  they  can  also bypass SBCSPROJ
     directives is thus of no consequence.

SBCS Release 1.2    Last change: 1 April 1994                   3

     It is possible to use SBCSPROJ to define a  standard  source
     tree.   If  the  source_tree variable is defined in the file
     pointed at by SBCSPROJ,
          source_tree = "$HOME/projX/work:/home/projX/source"
     all  project  members  will  automatically  have  their  own
     $HOME/projX/work  directory  become their work area (g-node)
     linked to the official source node (s-node).  In this  case,
     project  members  do  not  have to put their own source tree
     definition in  their  SBCSENV  file  (and  may  be  able  to
     dispense  with their own environment file altogether).  This
     feature is possible because source_tree is expanded  by  the
     shell;  source_tree is the only sbcsenv variable expanded by
     the the shell (/bin/sh).

COMPARISON WITH SCCS
     Some UNIX systems provide an interface called  sccs  to  the
     SCCS  commands.   That  interface  is similar in idea to the
     sbcsproj presented here.  Among  the  differences  are  that
     with  sbcsproj,  all  SBCS  commands  can  be run, all their
     options can be used, and no new commands are introduced.

     The sccs interface recognizes new commands  such  as  delget
     and  deledit;  in  SBCS  these have been built directly into
     SBCS command options (ndelta -G, ndelta -E).

     The sccs interface can automatically prefix s-file arguments
     with  s.  and  look  for  s-files  in a separately specified
     directory.  sbcsenv also  provides  prefixing  (auto_prefix)
     and   the  more  general  source  tree  directory  hierarchy
     (source_tree).

SEE ALSO
     psd(1), sbcsenv(1), sbcsproj(1), sfile(1).

SBCS Release 1.2    Last change: 1 April 1994                   4

Return to SBCS Commands manpage index