Configuring and the File System -- Outlying Files and Security Issues

The Sun WorkShop TeamWare Configuring tool identifies a workspace as a directory that contains a local subdirectory named Codemgr_wsdata. In all other respects, a Configuring workspace is a directory like any other in the file system.

Because a workspace is a directory, it and the files it contains are governed by the same ownership and permissions settings that govern other directories. Therefore, a workspace is subject to the effects of commands from both Configuring and the operating system. While this arrangement provides a high degree of flexibility, it introduces the potential for circumventing the automation and security features built into Configuring.

This topic describes ways you may want to take advantage of the directory nature of workspaces and ways you can protect workspaces from inadvertent file system manipulation.

Copying and Linking Outlying Files

Some builds require the use of files that are not under SCCS control. Such files may be derived files or source files that are not a part of the development project. Examples of such files are shared libraries and standard header files. Because these files are not under SCCS control (or are not in the project's release workspace), they are not copied between workspaces with Configuring transaction commands. Such files are sometimes called outlying files.

There are two common ways to incorporate outlying files into your build automatically: with symbolic links or by copying the files directly into a development workspace.

Makefiles

A developer can establish symbolic links to outlying files from his development workspace. Symbolic links are best described by makefile rules so that make can establish them at the beginning of a build. The make command can guarantee that linked binaries are up to date, and describing the links in makefiles produces a build structure that works without the presence of Configuring. The makefile rule shown in Figure 38 is an example.

Figure 38 Makefile Rule That Makes Symbolic Link

...

# Ensure that the symbolic link speclib.a

# is made to the file /usr/lib/speclib.a.

speclib.a : /usr/lib/speclib.a

ln -f -s /usr/lib/speclib.a speclib.a

...

Figure 38 Makefile Rule That Makes Symbolic Link
... # Ensure that the symbolic link speclib.a # is made to the file /usr/lib/speclib.a. speclib.a : /usr/lib/speclib.a ln -f -s /usr/lib/speclib.a speclib.a ...

To improve performance, a developer may want to copy a file directly into the workspace instead of establishing a symbolic link. Once again, this action can be conveniently performed in a makefile, as shown in the fragment of Figure 39.

Figure 39 Makefile Rule That Copies a File

...

# Ensure that the file /usr/lib/speclib.a

# is copied into the current working directory

speclib.a : /usr/lib/speclib.a

cp -p /usr/lib/speclib.a speclib.a

...

Figure 39 Makefile Rule That Copies a File
... # Ensure that the file /usr/lib/speclib.a # is copied into the current working directory speclib.a : /usr/lib/speclib.a cp -p /usr/lib/speclib.a speclib.a ...

Wrapping Configuring Commands

Another approach is to wrap the bringover and putback commands in executable shell scripts. The wrappers can copy the necessary files before issuing the bringover or putback, effectively automating the process. Wrappers are typically linked symbolically to the command name (bringover or putback), and the symbolic link is placed in the execution directory in place of the original executable. The original executable is moved to another directory, from which it is called by the wrapper.

The simple wrapper shown in Figure 40 copies the file /usr/lib/speclib.a into the current working directory, then issues the bringover command from the /cmgr directory.

Figure 40 Wrapper Script for the Bringover Command

#!/bin/sh -

#

# Name: .wrapper_bringover

# This script intercepts a bringover command, copies a

# a file into the current working directory, then issues

# the bringover.

#

progname=\Qbasename $0\Q

filename="/usr/lib/speclib.a"

cp -p $filename .

echo "$filename has been copied to the current working directory."

# Issue original command, if it can be found.

if [ -f $progname ]

then

eval exec /cmgr/$progname $opts '"$@"'

else

echo >&2 "Sorry, /cmgr/$progname was not found."

exit 1

fi

exit

Figure 40 Wrapper Script for the Bringover Command
#!/bin/sh - # # Name: .wrapper_bringover # This script intercepts a bringover command, copies a # a file into the current working directory, then issues # the bringover. # progname=\Qbasename $0\Q filename="/usr/lib/speclib.a" cp -p $filename . echo "$filename has been copied to the current working directory." # Issue original command, if it can be found. if [ -f $progname ] then eval exec /cmgr/$progname $opts '"$@"' else echo >&2 "Sorry, /cmgr/$progname was not found." exit 1 fi exit

Wrapper scripts can also be used to establish symbolic links in the current working directory. They work equally well from the command line or the graphical user interface (GUI), because the GUI itself performs bringover and putback transactions by issuing commands in a shell.

Security and Access Control

User accessibility to workspaces is controlled by the Codemgr_wsdata/access_control file in each workspace. Entries in this file determine which users can initiate bringover and putback transactions, and who can delete, reparent, and move the workspace. Control at this level is adequate to prevent unauthorized access to workspaces by users who execute Configuring commands. Users still have access to workspace directories with operating system commands, however.

For example, a user who possesses the correct passwords and permissions can change directories to a workspace, check out a file from the Source Code Control System (SCCS), edit it, and check it back in. Such an action short-circuits Configuring's file tracking system and is especially worrisome at the release workspace level, where a developer might mistakenly check in a file without the authorization of the release-level integration engineer.

One development group addressed the problem by selectively setting the permissions of the exported directories in its workspaces. Permissions were set as follows:

Because Configuring transactions must write to a locks file in the Codemgr_wsdata directory, that directory was set to be writable by anyone.
The usr directory, which was the root of the source file hierarchy, was exported read-only to all but one file system so that it could not be written to casually.
The usr directory was exported read-write to only one machine, which developers had to log into remotely (rlogin) before they could put back. That machine was protected by password from remote logins by unauthorized users.

Of course, no system of controls is really adequate to protect files from authorized users with malicious intent. The real value of the arrangement just described was that qualified users had to perform the extra step of logging into the machine before putting back. This extra step protected from unintentional source file checkins by ensuring a conscious step on the part of developers before they put back source files.