 Asserting
File Attributes Using SolarisTM Packages
Ed Schaefer and John Spurgeon
Over time, file attributes in a multi-user environment tend to
drift from their original values. Some of these changes are acceptable,
but detecting and correcting undesirable modifications can be a
challenge for systems administrators.
When installing software packages on Solaris, the file /var/sadm/install/contents
is updated with information about the components of each package.
Using this information, a program can compare the current attributes
of a file with the attributes documented in the contents file. If
differences are detected, the program could generate an alert. For
attributes, such as the owner, group, or permissions mode, the program
could even change them back to their original values.
If you are not familiar with Solaris packages, your first reaction
upon learning about the contents file might be to develop a program
that parses the file to retrieve the attribute data. However, depending
on your objective, there may be a better solution. Below, we'll
analyze two shell scripts: one that accesses the contents file directly
(assert_attributes_1), and another that uses the pkgchk command
(assert_attributes_2). To begin, let's look at the anatomy of the
contents file:
/var/sadm/install/contents
The contents(4) manpage provided with Solaris 10 describes
the file /var/sadm/install/contents. In previous versions of Solaris,
this manpage was not included in the reference manual. (Online copies
of the Solaris manuals are available at http://docs.sun.com.)
Each entry in the contents file is a single line with fields separated
by spaces. Two major styles of entries exist -- old style and new
style.
The following is the format of an old-style entry:
ftype class path package(s)
The following is the general format of a new-style entry:
path[=rpath] ftype class [ftype-optional-fields] package(s)
The "ftype" designates the entry type, as specified in pkgmap(4):
s -- Symbolic link
l -- Linked file
d -- Directory
b -- Block special device
c -- Character special device
f -- A standard executable file, data file, or other type of file,
the contents of which must never be modified
x -- An exclusive directory accessible only by this package
v -- A volatile file, intended to be overwritten or appended to
after installation
e -- An editable file, intended to be edited (selectively modified)
after installation
New-style entries differ for each ftype. The format for new-style
entries, for each ftype, is as follows:
path=rpath s class package
path l class package
path d class mode owner group package(s)
path b class major minor mode owner group package
path c class major minor mode owner group package
path f class mode owner group size cksum modtime package
path x class mode owner group package
path v class mode owner group size cksum modtime package
path e class mode owner group size cksum modtime package
Here are some examples of entries from one of our contents files:
/opt/fics d none 0775 informix informix FICSskel
/opt/fics/bin/autocccftp f none 0444 informix informix 40 3383 1054 FICSskel
Reviewing the assert_attributes_1 Script
The following is the programming logic for the assert_attributes_1
script (Listing 1). For each package passed to the script:
1. Obtain the file and directory ownership and permissions from
the /var/sadm/install/contents file.
2. Save the current object's ownership and permissions.
3. Set the object's ownership and permissions to those obtained
in Step 1.
4. Compare the new with the original ownership and permissions
and raise an alert if they are different.
Finding Package Objects
If no packages are listed on the command line, the list_files
function queries standard input for package information until the
user presses Control-d.
Next, the list_files function determines each line in the
contents file belonging to each package, and returns the first,
second, fourth, fifth, and sixth fields.
Processing Package Objects
The output of the list_files function is piped to a while
loop that processes the five arguments. If an object is a symbolic
link, the object name structure looks like this:
path1=path2
Using parameter expansion file=${file_equals%=*} removes the
equal sign and everything else from the end of the string. For example,
object name:
/opt/fics/admin=/opt/admin/bin
becomes after parameter expansion:
/opt/fics/admin
As each line is parsed, only files -- both regular and volatile --
and directories have their ownership and permissions set.
Setting Object Ownership and Permissions
In the assert_attributes function, the owner/group and
permissions are set by the chown and chmod commands,
respectively. Before the commands execute, the object's ownership
and permissions are saved by a call to the list_attributes
function. If the attributes change after executing chown
and chmod, the script generates an alert.
We described our alerts in "Managing Enterprise Alerts" (Sys
Admin, April 2004). If you haven't implemented our alerts, replace
this code with your own.
Reviewing the assert_attributes_2 Script
By manipulating the pkgchk command, the assert_attributes_2
script (Listing 2) also sets ownership and permissions to the original.
Executing pkgchk -a against a package reports any attribute
discrepancies to standard error. If there are any discrepancies,
execute pkgchk -a -f package_name setting the attributes
back to the original and create an alert.
References
"Application Packaging Developer's Guide" -- http://docs.sun.com/app/docs/doc/805-3908
contents(4) man page -- http://docs.sun.com/app/docs/doc/816-5174/6mbb98udu?a=view
pkgmap(4) man page -- http://docs.sun.com/app/docs/doc/816-5174/6mbb98uid?a=view
John Spurgeon is a software developer and systems administrator
for Intel's Factory Integrated Information Systems, FIIS, in Aloha,
Oregon. He is currently training for the Furnace Creek 508 and still
enjoys turfgrass management, triathlons, and spending time with
his family.
Ed Schaefer is a frequent contributor to Sys Admin.
He is a software developer and DBA for Intel's Factory Integrated
Information Systems, FIIS, in Aloha, Oregon. Ed also edits the monthly
Shell Corner column on UnixReview.com. He can be reached at: shellcorner@comcast.net. | 
