It is uncommon to find an SCO system that does not have users on it.
Although there are "system" users that have the same
characteristics as human users, these are not what we normally think
of when talking about users. For us, a user is a person that
interacts with the system. This can be anything from logging in and
getting to a shell prompt or accessing files on a remote system by
using various networking programs.
Users are what computers are made for. One of the key advantages that
UNIX has over operating systems like does is that it was designed to
run with multiple users, all accessing the same system and resources.
It is important that the system not only be able to distinguish
between different users, but also make decisions about what each user
can and cannot do.
In this chapter, we are going to talk about what makes a user. We'll
look at what the operating system sees as a user. In other words,
what files, values and data goes into the system's interpretation of
a user. We'll also talk about what a user can and cannot do, plus the
mechanisms that are in place to prevent a user from doing something
he or she shouldn't. This is the whole idea behind system security.
Users gain access to the system only after the system administrator
has created user accountsfor them. These accounts are
more than just a user name and password, but also define the
environment the user works under including the amount of access he or
Users are added to SCO UNIX Systems by one of two ways. The most
common way is through the System Administration Shell (sysadmsh)
in ODT 3.0 and the Account Manager in OpenServer. Here the system
administrator can define the basic aspects of a user's account. The
other way is by means of the addxusers,
which is used to add users when movingfrom SCO XENIX, or from other
systems that do not have the level of security as SCO UNIX. Although
this does not allow you the detail of control you get when adding
users the "official" way, you do have the ability to
incorporate this command into a shell script to automate adding
users. We'll take more about both of these a little later.
Adding a user to an SCO UNIX system is often referred to as "creating
a user" or "creating a user account." The terms "user"
and "user account" are often interchanged in different
contexts. For the most part, the term "user" is used for
the person actually working on the system and "user account"
is used to refer to the files and programs that create the user's
environment when he or she logs in. However, these two phrases can be
interchanged and people will know what you are referring to.
When an account gets created, a shell is assigned along with the
default configuration files that goes with that shell. Users are also
assigned a home directory, which is their default directory when they
login. This is usually of the form /usr/<username>.
Note that the parent of the users' home directories may be
When user accounts are created, each user is assigned a User Name
(login name or logname), which is associated with a User ID (UID).
Each is assigned to at least one group, with one designated as their
login group. Each group has an associated Group ID (GID).
The UID is numbers that is used to identify the user. The GID is a
number used to identify the login group of that user. Both are used
to keep track of that user and determine what files he or she can
In general, programs and commands that interact with us humans report
information about the user by logname or group name. However, most
identification from the operating systems point of view is done
through the UID and GID. The UID is associated with the logname of
the user. The GID is associate with the login group of the user. In
general, the group a user is a part of is only used for determining
access to files.
With the exception of the security related information (which we
cover in detail in the next section), all the user information is
kept in two files: /etc/passwd
and /etc/group. For
details of the contents of these files, see the passwd(F)
If you look on your system you will see that both of these files are
readable by everyone. My first reaction was that this was a security
problem, but when I was told what this was all about, I realized that
this was necessary. I was also concerned about the password be
accessible, even in encrypted format. Since I know what my password
is, I can compare my password to the encrypted version and figure
out the encryption mechanism, right? Nope! It's not that easy.
At the beginning of each encrypted password is a seed. Using
this seed, the system creates the encrypted version. When you login,
the system takes seed from the encrypted password and encrypts the
password that you input. If this matches the encrypted password, you
are allowed in.
There is nowhere on the system that stores the unencrypted
password, nor do any of the utilities or commands generate it.
Next, let's talk about the need to be able to access this
information. Remember that the operating system knows only about
numbers. When we talked about operating system basics, I mentioned
that the information about the owner and group of a file was stored
as a number in the inode. However, when you do a long listing of a
file (ls -l) you don't see
the number, but rather a name. For example, if we do a long listing
of /bin/mkdir, we get:
-rwx--x--x 1 root sys
7558 Mar 15 1993 /bin/mkdir
The entries are:
permissions links owner group
size date filename
Here we see that the owner of the file is root
and the group is sys.
Since the owner and group are stored as numerical values in the inode
table, the system must be translating this information before
it displays it on the screen. Where does it get the translation? From
the /etc/passwd and
/etc/group files. You can
see what the "untranslated" values are by doing an ls
-ln /bin/mkdir, which gives us:
-rwx--x--x 1 0 3
7558 Mar 15 1993 /bin/mkdir
If we look in /etc/passwd,
we see that the 0 is the UID for root
and if we look in /etc/group
we see that 3 is the GID for the group sys,
which are the numbers we got above. If the /etc/passwd
and /etc/group files were
not readable by everyone, then no translation could be made like
this, without some major changes to most of the system commands and
utilities. Keep in mind that the GID only has meaning in terms of
If the SCO UNIX system you are working on was installed with a high
level of security, some other files come onto the scene. If you have
any security level other than "low", the encrypted
password is stored in the file /etc/shadow.
This file is readable only by root and contains the user name and
encrypted password, as well as longevity information about the
password. Because the encrypted password is stored in the
/etc/shadow file, an 'x'
will appear in the /etc/passwd
file in place of the encrypted password. For more details, see the
section security and the shadow(F)
Although they exist at all security levels, the files of the
Protected Password Database become an issues at levels above "low".
These files contain information about privileges that each user has
on the system. (We talk more about this in the section on security.)
In addition to user specific information, there are system defaults
related to logging in and password that are defined in
On a number of occasions, I have talked to customers that claimed to
have experienced corruption when transferring files from one system
to another. Sometimes it's with cpio
sometimes it's tar. In
every case, files have arrived on the destination machine and have
had either "incorrect" owners or groups and sometimes both.
Sometimes, the "corruption" is so bad that there are no
names for the owner and group, just numbers.
Numbers, you say? Isn't that how the system stores the owner and
group information for the files? Exactly. What does it use to make
the translation from these numbers to the names that we normally see?
As I mentioned, /etc/passwd
When you transfer files from one system to another, the only owner
information that gets transferred are the numbers. When the file
arrives on the destination machine weird things can happen.
Let's look at an example.
At SCO, my user name was jimmo and I had UID 12709. All my files
were stored with 12709 in the owner field of the inode. Let's say
that I create a user on my machine at home, also named jimmo. Since
there are far fewer users on my system at home than at SCO, jimmo
ended up with UID 200.
When I transferred files from work to home, the owner of all "my"
files was 12709. That is, where there normally is a name when I do a
long listing, there was the number 12709, not jimmo.
This reason for this is that the owner of the file is store as a
number in the inode. When I copied the files from my system at work,
certain information from the inode was copied along with the file.
This included the owner. Not the user's name, but the numerical value
in the inode. When the files were listed on the new system, there was
no user with UID 12709, therefore no translation could be made from
the number to the name. The only thing that could be done was to
display the number.
This makes sense because what if there were no user jimmo
on the other system? What value should be displayed in this field? At
least this way there is some value and you have a small clue as to
what is going on.
In order to keep things straight I had to do one of two things.
Either I create a shell script that changed the owner on all my files
when I transferred them, or I figure out some way to give jimmo UID
12709 on my system at home. And that's what I did.
Here, too, there are two ways I can go about it. I could create the
12508 users on my system and then the 12709th would be jimmo (Why
12508? By default the system starts with a UID 200 for normal users).
This bothered me cause I would first have to remove the user jimmo
with UID 200 then create it again. I felt that this would be a waste
The other alternative was to change the system files. Now, there is
nothing that SCO provided that would do that. There were many aspects
of the user jimmo that I could change, however, the UID was not one
of them. After careful consideration, I realize there was a tool that
SCO provided to make the changes: vi. Since this information is keep
in simple text files, you can use a text editor to change them. After
reading the remainder of the chapter you should have the necessary
information to make the change yourself.
Note that when you create a user you are offered a value for the UID.
This is usually one higher than the previously assigned UID. However,
you do not have accept this value. You can give any value you want
provided it has not already been assigned.
When the first customer called with the same situation, I could
immediately tell him why it was happening, how to correct it, and
assure him that it worked.
You can also change a user's group if you want. (How, I'll get to
later.) However, you don't have to go through all that, since this is
one of the changes you can make through the sysadmsh.
Remember, however, that all this does is change the GID
for that user in /etc/passwd.
Nothing else! Therefore all files created before you make the
change, will still have the old group.
There is a way of changing your UID while you are working. This is
done with the su command.
What does su stand for?
Well, that's a good question. I have seen several different
translations in books and from people on the net. I personally say
that it means "switch UID" as that's what it does. However,
other possibilitie include "switch users" and "super-user."
What this command does is set your UID to a new one. The syntax is:
where <user_name> is the logname of the user whose UID you want
to use. After running the command you have a UID of that user.
However, there is more to it than just that. The system also keeps
track of the UID that you logged in under. This is your login UID or
LUID. The LUID is maintained by the process and all of its
descendants for as long as they run. Nothing can change it. To check
your LUID, run:
We can also change our GID, as well. This is done with the newgrp
or sg commands. The sg
command is new and has many more options than newgrp.
We need to remember that a shell is the primary means that that users
gain access to the system. Once they do gain access, their ability to
move around the system (in terms of reading files or executing
programs) is dependent on a couple of things: permissions and
Permissions are something that most people are familiar with if they
have ever worked on an SCO UNIX (or similar) system before. Based on
what has been granted, different users will have different access to
files, program and directories. You find out what permissions a
particular file has by doing a long listing of it. The permissions
are represented by the irst 10 characters on the line. This is
something that we covered in a fair bit of detail in the section on
shell basics, so there is no need to repeat it here.
Privileges or authorizations are given at the time the user is
created, but can be changed later. Although you could do this
by editing the files directly, it is better (read: safer) to use the
tools that are provided for that purpose: sysadmsh
on ODT 3.0 and scoadmin on
OpenServer. Be very careful when granting privileges to users. Unless
there is some very compelling reason, you should not give users
anything more than what the default is. On a system with a lower
security level, the privileges granted to users are quite extensive.
If you seem to be giving users more that what the default is, then
maybe your security level is too high. See the section on system
security for more details on this.
A very dramatic example in ODT 3.0 is the "auth" system
privilege. This privilege is usually giving to root and user of the
type "administrator". By itself, it does have limited
power. However, there is a catch. Anyone with "auth" system
privileges has the ability to change any password on the system. I
repeat any password. So, although this user may not have root
privileges, all it needs to do is to change root's password and
login as root.
Logging into the System
User accounts are how users gain access to the system and is the
first level of security. Although it is possible to configure
applications that start directly on specific terminals, most everyone
has logged into an SCO UNIX system at least once. More that likely if
you are one of those people who never login, you never see a shell
prompt and are probably not reading this book.
Most SCO UNIX systems have a very standard login. You see the name of
the system, followed by a brief message (the contents of /etc/issue)
and the login prompt, which usually consists of the system name and
the word login. In OpenServer, the /etc/issue
is no longer present, by default. Instead, information is taken from
the file (/etc/default/banner).
Rather than be a straight, hard-coded text file like /etc/issue,
you to present "dynamic" information. The banner string is
defined in /etc/default/banner
as a set of variables that the system reads prior to presenting the
login. Afterwards you see the login prompts, such as:
If you do have something in both /etc/default/banner
and /etc/issue, you will
see the banner defined by /etc/default/banner
followed by the contents of /etc/issue.
When you log in, you are first asked your user name and your
password. Having been identified and password verified, you are
allowed access to the system. This often means that the system starts
a shell for you. However, many program can be used in place of a
One of the entries in the password file is your home directory. This
is the directory that you have as your current director when you log
in. This is also the place that the shell returns you to if you enter
cd with no arguments.
The Login Process
After determining your login shell and placing you in your home
directory, the system will set up some system wide defaults. If you
have a Bourne or Korn-shell, these are done through the
/etc/profile file. If you have ksh as your login shell, the
system runs through the commands stored in the .profile
in your home directory, then the .kshrc
file, provided they exist. If you have sh,
then there is no equivalent for the .kshrc
file. If you have a C-shell, the system defaults are established in
the /etc/cshrc file. The
system then executes the commands in the .cshrc
and .login files in your
home directory. Again, provided they exist. See the appropriate
man-page and the section on shell basics for more details.
During the login process, you are shown several pieces of information
about the local system. Prior to the login prompt, you usually see
the contents of the /etc/issue
file, as I mentioned above. After your login is successful, you will
normally see a message about the last successful and unsuccessful
logins, several copyright messages, and the message of the day. This
is the contents of the file /etc/motd.
There may be cases where all of this information is bothersome. For
example, many businesses have either menus that their users log into,
or applications that start from their users' .profile
or .login. In this case,
the information about copyrights and last login is of little value.
There are cases where even knowing that this is an UNIX system could
be a problem. There are many hackers in the world who would just love
the chance to try and crack your security. By not even telling them
what kind of system you have, you reduce the amount there are
tempted. As least, that's one more piece of information that they
need to figured out. Therefore, we need a way to disable these
The two obvious ones are /etc/issue
in OpenServer) and /etc/motd.
By default, both of these contain information about your system. By
either changing the contents or removing the files all together, you
can eliminate that source of information.
The next is the login prompt itself. Again, by default, this contains
the name of your system. This may not be of concern to most system
administrators, however in cases where security is an issue, I might
like to disable it. This comes from the /etc/gettydefs
file. The gettydefs file
contains information used by the getty
program when starting the login program on a terminal. The more
common lines in the gettydefs
file contain an entry that looks like this:
Take a look at the login prompt and you will see that it also
contains "!login:". Immediately following the name of the
system. The name of the system comes from the "@". By
changing either one of the parts (or both) you can change the
appearance of your login prompt, even removing the name of the system
if you want.
At this point we are left with the last login messages and the
copyrights. Unfortunately these are not contained in files that are
as easily removed as /etc/motd
and /etc/issue. However,
by creating a file we can remove them. This is the file
.hushlogin in your home
directory. It has no contents, rather the existence of this file is
the key. You can create it simply by changing to a users home
directory (yours, if you are that user) and running:
It's possible that your system administrator (if that's not you) has
disabled the hushlogin capabilities for the entire system. In which
case, you can create .hushlogin files all day and you will still see
the login messages. If you want to check, look for the ALLOWHUSH
entry in /etc/default/login.
If this is set to NO, then hushlogins are disabled system wide.
Often administrators want to keep users' knowledge of the system as
small as possible. This is particular important for systems with a
high level of security where users start applications and never see
shell prompt. One "give-away" as to what kind of system you
are on is the two lines when you login:
Last successful login for user...
Last unsuccessful login for
System administrators would regularly call into support asking for a
way to turn this off. Fortunately, there is a way. This, too, can be
disabled by creating the .hushlogin file. Once this functionality is
enabled, you can simplify things by having this file created every
time a new user is created. This is done by editing the file
Search for the line:
This will be within a function called "mk_home". You need
to add the line:
This will then create the file .hushlogin
in the user's home directory. For more details on this, take a look
at the part of this chapter on creating users as well as the system
One thing to consider before you turn this off, is that watching when
the last unsuccessful login attempt was may indicate a security
problem. If you repeatedly see unsuccessful login attempts when you
are not there, this is not a good thing. It may indicate someone is
trying to break into your account.
Restricting User's Access
It is also possible to not only restrict a user's access to files,
but also the commands that he or she can execute. The obvious
approach to this kind of thing is to change the permissions on the
files. However, this also limits access to others user who you want
to use them. You could make those user members of the appropriate
groups, but that gives them more access than you probably intended.
The best solution is to limit the access of those who should be
limited, rather than giving more access to the others. One solution
is the system authorizations that we will talk about in the next
section. However, this may not limit the user's access enough. The
solution to this is a restrictedshell. Each of the
three default SCO shells has a restricted version. Since their
functionality is basically the same, I will limit myself to talking
about the restricted version of sh:
In principle, it's behavior is the same as sh,
with the exception that you cannot change directories with cd
to anywhere other than the sub-directories of your home directory. In
addition, yyou cannot set your PATH variable or redirect standard
output. Another significant limitation is that you cannot execute
commands or programs using any path components, that is anything
containing a slash (/).
These means that any program you want the user to be able to execute
must be in the PATH.
This brings up another interesting issue in that the default path for
restricted shell users is only the $HOME/bin
directory. Since this is empty by default, the user's access is very
limited indeed. Therefore you need to ensure that the appropriate
programs are copied into the user's $HOME/bin directory. However, be
very careful what programs you give a user. The default owner on the
$HOME/.profile is the user. If you gave that user access to something
like vi they could edit
the .profile and change
When a shell script is executed rsh
invokes sh to execute it.
Therefore, the restrictions no longer apply so you can give end users
access to certain functional through such scripts, without opening up
everything to them. For example, you might want to give users a
startup up menu that gives the a choice of programs to run. Even if
the figured out how to break out of the program and get to a shell
prompt, they would still be limited by the restrictions of rsh.
As I mentioned before there are two ways standard ways of adding
users to the system. The most common method is through the menuing
interfaces provided. In ODT 3.0 this was sysadmsh,
in OpenServer this is the Account Manager. In order to ease the
transition from SCO XENIX there is also the addxusers
Although this alleviates many problems it does not help
administrators who have brand new systems and need to create dozens,
or even hundreds of users at once. Going through either the sysadmsh
or Account Manager with even a few dozen users can be very
tedious. If you were an experienced administrator, you could write a
shell script, combining some of the techniques that you learned in
the section on sed and
awk, that would edit the
necessary files and add the appropriate entries. The problem is the
one place where you forget the semi-colon (or whatever) and all of
the entries are useless.
Fortunately, there is an answer in OpenServer. Three new commands
were included that allow you to add, remove and modify user accounts.
These are, respectively, useradd,
usermod. Despite the introduction of these commands, and
despite the different programs used in each operating system, what
lies behind the scenes when adding (or removing) a user remains the
The most obvious (or at last most familiar) thing is the addition of
lines to both the /etc/passwd
and /etc/group files. As I
mentioned before, if your system is at a security level higher that
"low", an entry will also be created in /etc/shadow.
However, entries are created in the secuity database at every level.
Entries are also made into the security database, regardless of
what security level. I go into details about the security databases
in the section on security. However, we have one of those chicken-egg
things. In order to understand the process of adding a user I need to
jump ahead a little to talk about the security databases.
There are two databases that divide the privileges each user has into
two different perspectives. One contains a set of files, one per
user, that lists the privileges that particular user has. The
other is also a set of files, but here there is one file per
privilege, listing which user has that privilege. This redundancy
is to ensure the integrity of the security database as well as making
access of the necessary information easier.
As I mentioned before, each user is given a home directory. This may
be one that already exists, or a new one. If the directory is new,
the system will automatically make copies of the shell start-up files
in that directory based on which shell is selected. Then, that user
is made the owner and his or her group is made the group of those
files. The originals of these start-up scripts are kept in
sub-directories in /usr/lib/mkuser.
There is one directory for each of the possible login shells. These
can be easily modified by the system administrator to make changes to
the default shells.
As the user is created, there are a set of defaults that are
assumed. These are found in /etc/default/authsh .
They include, the home directory, the shell, the permissions on the
home directory and the type of user. Since this file is readable, any
user can see what the defaults are. In OpenServer, this is, instead,
the file /etc/default/accounts.
Whenever you are working on the with an application what you are
seeing is governed by a couple of processes. If you have a serial
terminal, the flow of data is controlled by the serial line
characteristics. This includes the baud rate, the number of data
bits, parity and so on. One aspect that is often forgotten or even
unknown to many users is the terminal characteristics. The terminal
characteristics are used to control the physical appearance on the
As I mentioned previously, the serial line characteristics are
initially determined by the gettydefs file. These are often changed
from within the user's startup scripts (.profile, .login, etc). In
addition you can change them yourself by using the stty
command. Rather than jumping to changing them let's take a look at
what our current settings are, which is also done with the stty
command. With no arguments, stty
might give us something like this:
This shows the more "significant" terminal (stty) settings.
The top line shows us the input and output speeds, which we see is
9600 in both cases. On the second line, we see that parity is turned
off (-parity) and the
system sends a hangup signal on the last close of this port. This is
useful on modem connections to ensure that connection is actually
broken and you don't end up with large phone bills.
The switch (swtch)
character tells up what is used to switch between different shell
layers. Here is is defined as CTRL-@.
We can tell this, because in the output of stty, the caret (^)
indicates a control character. (See the shl(C)
man-page for more details)
The suspend character (susp)
tells the system what key is pressed to suspend the current job. This
is only valid for shells tha support job control. What happens when
you suspend a job is comparable to putting the process in the
background, although it does not continue working. This process can
be returned to forground operation with the fg
command, or can be restarted in the background with the bg
The other settings include echoing every character that is typed
(echo), on input map
charriage returns to new lines (icrnl)
and on output map new lines to carriage returns (onlcr).
Characteristics can be specifically turned off by including a minus
in front of them, such as -istrip
which says not to strip input characters to 7-bits.
Setting these values is very straight forward. For settings that are
Booleans (on or off), the syntax is simply:
to turn it on, or:
to turn it off.
For example, if I wished to turn on input stripping, the command
would look like this:
Settings that require a value have the sytnax:
stty <setting> <value>
So, to set the speed (baud rate) to 19200 the syntax would look like
stty speed 19200
or to set the suspend character to CTRL-Z we would enter:
stty susp ^Z
Note that ^Z this is not two seperate characters. Instead, when we
type it it we hold down the CTRL key and press 'z'. Here again, the
letter appears as capital although we pressed the lowercase letter.
If there are characteristics that the default output does not show,
you can use the -a option to show all the characteristics. You might
end up with output like this:
For details on what each of these entries mean, please see the
If you want to be able to save your stty settings, change some and
then restore the original values, you can use the -g
option. This outputs the stty settings as a strings of hexadecimal
values. For example, I might get something like this:
We can run the stty command to get these values, make the changes,
then run stty again and use these values as the argument. No, we
don't have to type in everything by hand, we simply take
advantage of the fact that variables are expanded by the shell before
being passed to the command. Let's look at the example in the SCO
echo "Enter your secret
stty -echo intr '^-'
We assign the output of the stty command to the variable old. We then
change the stty settings so that they characters we input are not
echoed to the screen and the interrupt key is disabled. We then read
a line from the keyboard and then reset the stty settings to their
If you are interacting with system solely through command line input,
then you have few occasions to encounter the terminal capabilities.
As the name implies, terminal capabilities determine what the
terminal is capable of. For example, can the terminal move the cursor
to a specific spot on the screeen?
The terminal capabilities are defined by one of two databases. Older
applications such as SCO's Lyrix use termcap, while newer ones use
terminfo. For the specifics on each, please see the appropriate
man-page. Here we are going to talk about the concept of terminal
capabilities and what it means to you as a user.
Within each of these database is a mapping of what character or
character sequence the terminal expects for certain behaviour. For
example, on some terminals pressing the backspace key sends a CTRL-H
character. On others, a CRTL-?
is sent. When your TERM environment variable is set to the correct
one for your terminal, pressing the backspace key sends a signal to
the system which then, in turn, tells the application that the
backspace characteristic was called. It is then up to the application
to determine what is to be done.
The key benefit of a system like this is that you do not have to
recompile or rewrite your application to work on different terminals.
Instead, you link in the appropriate library to access either termcap
or terminfo and listen for what capability the OS is sending you.
When the application receives that capability, it reacts accordingly.
There are three types of capabilities. The first are Boolean, which
determine if that terminal has a particular feature. For example,
does the terminal have an extra "status" liner? The next
type is numeric values. Examples of this are the number of columns
and lines the terminal can display. In some cases, this may not
remain constant as terminals such as the Wyse 60 can changed between
80- and 132-column mode. Lastly are the string capabilities which
provide a character sequence to be use to performa a particular
operation. Examples of this would be clearing the line from the
current cursor position to the end of the line, or deleting the
contents of an entire line (with or without removing the line
Despite the fact that there are hundreds of possible capabilities,
any given terminal will have only a small subset of them. In
addition, many of the capabilities do not apply to terminals, but
rather to printers.
Both the termcap database and the terminfo database have their own
advantages and disadvantages. The termcap database is defined by the
file /etc/termcap. This is
an ASCII file that is easily modified. In contrast to this is the
terminfo database which starts out as an ASCII file, but must be
"compiled" before it can be used. The default source file
compile the entries you use the terminfo compiler: tic.
The tic utility will then
place the compiled version in a directory under /usr/lib/terminfo
based on the name of the terminal. For example, the ansi terminal
ends up in /usr/lib/terminfo/a
and Wyse terminals end up in
SCO also provides you with a tool to convert existing termcap entries
to terminfo: captoinfo.
Cron is a commonly confusing and misconfigured aspect of the
operating system. Technically cron is just the clock daemon that
executes commands at specific times. However, there are a handful of
configuration files and programs that go into making up the cron
package. Cron is a system process that never ends. When cron
completes one job is done, it sleeps until it is is time to run the
The controlling files for cron are the cron-tables or crontabs. The
crontabs are located in
/usr/spool/cron/crontab. However, like many configuration
files, you need to tell cron that changes have been made. If you edit
the crontabs themselves, the changed will not take effect until you
reboot. (or go into multi-user mode)
Another thing to consider is that you should not edit the files
directly. You can edit them with a text editor like, vi.
However, there is the potential for messing things up. Therefore, you
should use the tool that SCO provides: crontab.
The crontab utility has
several functions. The first is that it is the means by which files
containing the cron jobs
are submitted to the system. Second, it can list the contains of your
crontab. If you are root, it can also submit and list jobs for any
user. The problem is that jobs cannot be submitted invididually.
Using crontab, you must
submit all of the jobs at the same time.
At first, that might sound a little annoying. However, let's take a
look at the process of "adding" a job. In order to add a
cron job, you need to first list out the contents of the existing
crontab. This is done with the -l option. If you are root and wish to
add something to another user's crontab, you use the -u option,
followed by their logname. You then redirect this to a file, which
you can then edit. For example, let's say that we are the root user
and want to add something to uucp's crontab. First, we get the output
crontab -l -u uucp
The file /tmp/crontab.uucp
now contains the contents of uucp's crontab. It might look something
Despite appearance, each crontab entry consists of only 6 fields. The
first 5 represent the time job should be executed and the 6th is the
actuall command. The first five fields are seperated by either a
space or a tab and represent the following units, respectively:
day of the month (1-31)
month of the year (1-12)
day of the week (0-6, 0=Sunday)
If you want to specify all possible values, you would use an
asterisk(*). You can specify a single value, by simply including that
one value. For example, the second line in the above example, has a
value of 10 in the first field. This means at 10 minutes after the
hour. Since all of the other four time fields are asterisks, this
means that the command is run every hour of every day at 10 minutes
past the hour.
Ranges of values are composed of the first value, a dash and the
ending value. For example, the four line has a range (1-5) in the day
of the week column. This means that the command is only executed on
days 1-5, Mon-Fri.
To specify different values, that are not within a range, the
individual values are seperated by column. In the fourth example, the
hour field has the two values 10 and 14. This means that at 10am and
2pm the command is run.
Note that times are additive. Let's look at an example,
10 * 1,16 * 1-5
The command is run 10 minutes after every hour on the first and
sixteenth as well as Monday through Friday. If either the first or
the sixteeth were on a weekend, the command would still get run as
the day of the month field would apply. However, this does not mean
that if the first is a Monday, the command is run twice.
To add and entry we simply include a new line. We save the file and
get out of our editor and run the crontab utility again. This time we
leave of the -l to list the file, but include the name of the file.
The crontab utility can also accept input from stdin, so you could
leave off the file name and crontab would allow you to input the
cronjobs on the command line. Keep in mind that any previous crontab
is removed no matter what method you use.
With the exception of certain error in the time fields, errors are
not reported until cron runs the command. All error and output
is mailed to the users. At least that's what the SCO doc says and
what is basically true. However, as we see in the above examples, we
are redirecting stdout to /dev/null. If we wanted to, we could also
redirect stderr there as well and we would never see if there were
The reason that output is mailed to the user is that there is no real
terminal that the cronjobs are being executed on. Therefore, there is
no screen to display the errors. Added to that, there is no keyboard
to accept input. Does that mean you cannot give input to a cron job?
No. Think back to the discussion on shell scripts in chapter 3. We
can redefine stdin, stdout and stderr. This way they can all point to
files and behave as we expect.
One thing I would like to point out is that I am not an advocate of
doing redirection in the command field of the crontab. I personally
like as little there as possible. Instead, put the absolute path to a
shell script. I can then test the crontab entry with something
simple. Once that works, I can make changes to the shell script
without having to resubmit the cronjob.
If you want to keep a record of what cron is doing, you need to set
the CRONLOG variable to YES in /etc/default/cron.
By default, logging is off. Note that nothing clears out the log by
default, so if you have a lot of cron activity the log file
get quite large.
Keep in mind that cron is
not exact. It basically puts itself to sleep for as many seconds as
necessary to reach the next job. On a busy system, where you loose
clock ticks, jobs may not get executed until a couple of minutes
after the scheduled time. In addition, there many be processes with
higher priorities that delay cron
Access is permitted to the cron
facility through two files, both in /usr/lib/cron.
If you have a file cron.allow,
you can specify which users are allowed to use cron. The cron.deny
says who specifical cannot. If neither exist, then only the system
users have access. However, if you want everyone to have access,
create an entry cron.deny
file. In other words, no one is denied access.
The next command in the cron "suite" is at.
It's function is to execute a command at a specific time. The
difference is that once the at job has run, it disappears from the
system. Like for cron,
there are two files, at.allow
and at.deny, which have
the same effects on the at
The batch command is also
used to run command once. However, commands that are submitted with
batch are run "when the system gets around to it." This
means that when the system is less busy, for example in the middle of
the night. It's possible that such jobs are spread out over the
entire day depending on the load of the system.
Regardless of what command was used to submit the job, all such
"delayed" jobs are scheduled by cron. There are normally
two queues for these jobs: one for cron and at and the other for
batch. Each of these queues has certain characteristics that are
determined by the file /usr/lib/cron/queuedefs.
If necessary, at jobs can be submitted to one of 26 queues using the
-q flag. One for each
letter of the (lower-case) alphabet. However, I have never heard of a
situation where there was need to use more than one. (If you have
one, I would love to hear it.)
The queuedefs file contains one line for each queue in the form:
Where Q is the queue name (lower case a-z),# specifies the maxmimum
number of running jobs in the queue, % specifies the nice value (used
to detemine scheduling priority), and & specifies how many
seconds in the future a job should be rescheduled if the maximum
number of running jobs has been reached. Note that the 'j', 'n' and
'w' must appear following their respective values. Since the trailing
letter indicates what the value represents, any one can be left out.
If so the default value is assumed. (100 maximum jobs, nice value=2,
retry in 60 seconds).
/usr/lib/cron/queuedefs file is:
The 'a' queue is used by cron and the 'b' queue is used by batch or
by at using the -qb
option. If you want to add new queues, you can simply edit this file
with any text editor.
One thing to note is the behavior of at
and batch. Both accept the
names of the commands from the command line and not as arguments to
the command itself. You need to first run the command and you are
brought to a new line, where you input the commands you want execute.
After each command press enter. When you are done, press CTRL-D.
Since these two commands are accepting commands from stdin, you can
input command without having to do so on a new line each time. One
possibility is to redirect input from a file. For example,
at now +1 hour < command_list
Where command_list is a
file containing a list of commands. You could also have at
(or batch) as the end of a
cat command_list | at now + 1
cat command_list | bacth
Another interesting thing about both at and batch is that they create
a kind of shell script to execute your command. When you run at
or batch, a file is
created in /usr/spool/cron/atjobs.
This file contains the system variables that you would normally have
defined, plus some other information that is contained in
essentially creates an environment as if you had logged in.
One question that comes up frequently when dealing with cron,
at and batch is what happens when the system time changes. Well,
before we jump into that we need talk briefly about UNIX time. Time
on almost all UNIX systems is measured in the number of seconds from
the "epoch" or 00:00:00 Greenwich Mean Time (GMT) on
January 1, 1970. You can change the system perception of what time it
is by changing the timezone or even making the system think the time
is different that what your wristwatch shows. However, the
representation the system gives to you is always based on the number
of seconds from the dawn of UNIX time.
When a job is submitted to cron,
it will calculate how many seconds from now until the job is supposed
to run. Cron will then set a kind of alarm clock to wake up when the
next job is supposed to run. This may be the job just
submitted or one that was alread submitted. (Note that when the
system boots up it checks all the queues for pending jobs and makes
the calculation accordingly.)
After cron executes a job, it needs to figure out when the next one
is due. If the current time is earlier than the event time for the
job that it just completed or the current time is more than minutes
later than the laste event, cron
assumes that the system clock has changed. When this happens cron
deletes all events from it's internal tables and and re-reads the
entries from the cron
Since batch jobs are
executed when the system load permits, they are uneffected. Any at
job that was supposed to be already executed by this new time are
executed immediately. If the job is still in the future, the new time
to wait is calculated. Keep in mind that once an at
job is run, it is removed from the queue. Therefore, at jobs are
always executed only once.
Cron jobs are differnt
since they are re-occurring. When the time change is recognized, jobs
scheduled for the future are recalculated. Let's take an example
where a cron job is
scheduled for 10AM every day. At 9:55AM we move the clock forward to
10:05. Since the next time the job is scheduled is 10:00AM tomorrow,
we miss once instance. On the other hand, if at 10:05AM we set the
clock back to 9:55AM, the job will be repeated as 10:00AM.
One important aspect of cron
is that it does not run with a login UID (LUID). This is because it
was started by init as the system was going into multi-user mode. If
cron dies for some reason, then you cannot simply start it by hand.
This would cause cron to start with your LUID, which would cause cron
to fail. Instead, you need to use the sd
program. This simply starts a program without a LUID. However, you
cannot start just any old program. In order to run the program with
sd, it must be listed in
See the sd(ADM) man-page
for more details.
Well, why would cron die?
Well, one reason is submitting an at job to the "c" (cron)
queue when running ODT. Any other queue seems to work fine accordning
to my tests. When the at job is run, a core file is left behind in
the at spool directory /usr/spool/cron/atjobs
and if you will find that the cron process is no longer running.
Even if you try to restart cron with the sd command, it will fail do
to the presence of the file /usr/lib/cron/FIFO.
The solution to this problem is to remove all the atjobs in the spool
directory as well as /usr/lib/cron/FIFO.
Next, restart cron using
the sd command.
The term security is common enough. On a personal basis we
think of it as freedom from risk or danger; being safe. We might also
think of this as the methods we undertake to prevent someone from
breaking into our house. In computer science terms, both of these
ideas are applicable, depending on what you are referring to.
If we talk about being safe from risk when working with computers, we
are often talking about things like regular backups and reliable
hardware. Although these are very important issues, these are not
what is generally meant when referring to security. On computers
systems, security is more along the lines of preventing someone from
breaking in. The definition can be expanded by saying computer
security is preventing someone from doing something that they are not
allowed to do. This could be anything from reading other people's
mail to stopping the printers.
In this section we're are going to be talking about what mechanisms
exist to keep people from poking around and doing things they
shouldn't. We'll talk about what tools SCO UNIX provides
to control access, change what users can access and how to make sure
users are not even trying to do things they shouldn't.
In any information system, whether it is a computer or filing
cabinet, there are some basic security issues that need to be
considered. First, there is one aspect of security that no operating
system can help you with: the physical security of your system. You
might have all the security implemented that SCO UNIX provides, but
if someone can walk off with your computer, even the highest levels
of operating system security don't do any good. Just as a
security policy in an office has no effect if someone can just walk
away with sensitive files.
One of the easiest and most effective types of physical security is
simply a locked door. This prevents the "crime of opportunity”
from ever happening, such as someone from just walking away with
pieces of equipment, or the whole machine for that matter. The only
thing that can prevent this kind of theft is more elaborate security
measures that are beyond the scope of this book. However, it is
something that you must give serious thought to. Locking the door to
the computer can also prevent people from breaking into the system.
Anyone who has a set of installation disks or an emergency boot disk
set can gain access to your system if they have access to the
There is also access to the all powerful root account. On an SCO
system root can do anything. Although it is possible to restrict
roots access to certain functions, a knowledgeable user with root
privilidges can overcome that. There are many instances where you
have several people administering some aspect of the system, such as
printers or the phsyical network. I have seen it myself where one
person says "Well, he has root access, why can't I?"
Access to the root account should be limited for a couple of reasons.
First, the more people with root access, the more people who have
complete control over the system. This makes access control
Also, the more people that have root access, the more fingers get
pointed. I know from experience that there are people who are going
to deny having done something wrong. Often this results in a corrupt
system as there are everyone has the power to do everything, someone
did something that messed up the system somehow and no one will
admit. Sound familar?
The fewer people that have root, the fewer fingers need to be pointed
and the less people can pass the buck. Not that what they did was
malicious, mistakes do happen. If there are few people with root
access and something goes wrong, tracking down the cause is much
Rather than several users all having the root password, some people
think that it is safer to create several users all with the UID of
root. Their belief is that since there are several lognames, it's
easier to keep track of things. Well, the problem in that thinking is
that the system keeps of track of users by the UID. There is no way
to keep these users separate, once they log in.
My personal suggestion is that if several users need root powers,
that you make it company policy that no one logs in as root. Instead,
you grant each required user the su system privilidge. They then
login with their own account and do an su
to root. Although everything is still done as root, there is
a record of who did the su in
Another aspect of physical security is access to the machine itself.
It may be impractical for someone to walk off with your computer.
However, an knowledgeable user with root access to a comparable SCO
system can gain access to yours if they have physical access. Even
without access to another system, if that user has access to the
installation floppies, they can get into your system.
The next issue is privacy. This can be the company's privacy or
that of individuals. You don't want unauthorized users to have access
to payroll records, just as you don't want to have access to
other employees personal files. One of the most commonly ignored
aspects of this is the power of small pieces of information. As
individual items, these pieces may have no significance at all.
However, when taken in context they can have far reaching
implications. Police use this same concept to investigate crimes and
intelligence agencies like the CIA use it as well. Extending this to
the business world, such techniques are useful for corporate spies.
What if someone came along a changed an important piece of
information? For example, an employee who thinks he is underpaid may
want to change how much he was getting paid. Whether this information
is on paper or in a computer, the integrity of the data is an
important part of security. Along the same lines is the consistency
of the data. You want the same behavior from the system is identical
situations. For example, if salary is based on position, inconsistent
data could mean that the night watchman suddenly gets paid as much as
the company president.
Another aspect is the concept of auditing. Like an audit of a
company's books, auditing in a computer security sense is
record of the transactions or events that occurred on
the system. This allows the system administrator to follow the tracks
of suspected perpetrators and maybe catch them in the act.
Regardless of what security issue you are talking about, any breach
in security can be prevented by not allowing access to the system.
Now, this can be taken to extremes by not letting anyone to
have access. However, by limiting access to the system to only
authorized users, you substantially lower the risk of breaches in
security. Keep in mind that there is no such thing as a secure
system. This is especially important when you consider that the most
serious threat comes from people who already have an account on that
Access control has been a part of UNIX for a long time. It is a
fundamental aspect of any multi-user system. The most basic form of
access control is in the form of user accounts. The only way you
should be able to gain access to an SCO UNIX system is through an
account. Users usually gain access to the system when they have an
account set up for them. Each user is assigned an individual password
that allows them access. In some cases, this password may be blank
meaning you only need to press enter. In other cases it can be
removed altogether so you are never even prompted to input your
Removing the password may not always be a good idea. In fact, SCO
UNIX allows the system administrator the option to prevent users from
either having no password or having to just press return. Since we
are talking here about security and accounts without passwords are
not very secure, we'll restrict ourselves to talking about
accounts that have passwords.
Built into SCO UNIX are some enhancement to simple passwords that
prevent one of the more common security breaches: letting someone get
access to your password. If you write your password on to a Post-It
and stick it on your monitor, then no operating system in the world
can do anything about it. But what about cases where you
inadvertently give someone your password?
This happens when users choose passwords that are easily guessed by
someone trying to break in. Often users will choose passwords that
are easy to remember, such as their license plate number or spouse's
birthday. SCO UNIX cannot do anything to keep you from using your
license plate number as a password. However, it does have some built
in features to limit what you can use.
Words that can be found in a dictionary are not good choices for
passwords. With just a few lines of code, you could write a simply
program that searched through a list of words and tried them all as
passwords. However, if activated, SCO UNIX will prevent you from
choosing any of these as your passwords. It also prevents you from
making simple changes to the password like rotating (strawberry
becomes awberrystr) or reversing (yrrebwarts).
Depending on how the system administrator implements it, SCO UNIX can
also prevent you from using things like the name of the system, the
word UNIX, and several other things. This can even be expanded by the
system administrator as to prevent you from using things like the
company's name as passwords. To help you in your choice, the
SCO UNIX passwd program
provides a password generator to create easy to remember, but
non-sensical password. Well, at least that's what the SCO doc says.
Personnally, I have found the generated password more of a problem
than "obvious" ones. Because the generated ones are
non-sensical, users are more likely to forget them and end up calling
the administrator. For more details on this, check out the goodpw
(ADM) and passwd(ADM)
Although this password protection stops most attempts to gain
unauthorized access to the system, many security issues involve users
that already have accounts. Unchecked, curious users could access
payroll information and find out what their boss gets paid. Corporate
spies could steal company secrets. Disgruntled workers could wreak
havoc, by destroying data or slowing down the system.
Once logged in, SCO UNIX (among other UNIX dialects) provides a means
of limiting the access of "authorized" users. This is in
the form of file permissions, which we already talked about. File
permissions are one aspect of security that most people are familiar
with in regard to UNIX security. In many cases the only kind of
security other that user accounts.
The first thing we need to talk about is the concept of a file
owner. Each file has an owner, whether or not some user
explicitly went out there and "claimed” ownership. It's
a basic characteristic of each file and is imposed upon them by the
operating system. The owner of the file is stored, along with other
information, in the inode table in the form of a number. This number
corresponds the User ID (UID)
number from /etc/passwd.
Normally, files are initially owned by the user who creates them.
However, there are many circumstances that would change the
ownership. One of the obvious one is that the ownership is
intentionally changed. Only the owner of the file and root can change
its ownership. If you are the owner of a file, you can, in essence,
"transfer ownership” of the file to someone else. Once
you do, you are no longer the owner (obviously) and have no more
control over that file.
Another characteristic a file is its group. Like the owner,
the file's group is an intrinsic part of the file's
characteristics. The file's group is also stored in the inode as a
number. The translation from this number to the group name is made
from the /etc/group file.
As we talked about in the section on users, the concept of a group
has only real meaning in terms of security. That is, who can access
What this means is that only "authorized” users can
access files in any of the three manners: read, write and execute. It
makes sense that normal users cannot run the fdisk
utility, otherwise they would have the ability to re-partition the
hard disk, potentially destroying data. It also makes sense that
normal users do not have write permission on the /etc/passwd
file, otherwise they could change it so that they would have access
to the root account. Since we talked about it in the section on shell
basics and on users, there is no need to go into more details here.
System Security Under SCO
In early versions of UNIX, account passwords and file permissions
were the only types of security implemented. As computers became more
widespread and those who wanted to gain unauthorized access became
more devious, it became apparent that this was not enough. Since the
US government was steadily increasing the number of agencies that had
computers, the level of system security needed to be increased as
In 1985, the National Security Agency's National Computer Security
Center (NCSC) created a set of computer security standards for the
Defense Department, titled "Trusted Computer Systems Evaluation
Criteria". This is commonly known as the "Orange Book"
as it was published with an orange cover. (This is part of a series
of documents by the DOD related to computer security, all with
different colored covers.)
Within the Orange Book, there are four broad classes of security
levels for computers:
The C class contains to sub-levels, C1 and C2, with C2 offering
slightly more security than C1. Class B offers three sub-levels: B1,
B2 and B3.
Traditional PC based operating systems, like DOS and Windows fall
within class D. This minimal protection does not mean there is no
security, just that it is not as high as the C class. You can buy
add-on products to add passwords to your system or change the file
attributes to prevent accidental erasure. There are even product
available that will allow you to, but that's about it.
Class C systems include the features and functions to employ
discretionary protection. That means that it is up to the
system administrator's discretion to decide how much access people.
(What this means, we'll talk about in a minute.) Class C1
systems offer enough security to let users keep their data private
from other users and prevent it from being accidentally read or
destroyed. As we've already talked about, standard UNIX already
provides this level of security in the form of user passwords and
Class C2 demands tighter login procedures, auditing of security
related events, and isolation of system resources. This is the level
that is provided by SCO UNIX. Since it is at the discretion of
the system administrator, it may not be in place on your system.
B-Class systems implement mandatory protection. That
is, the system administrator cannot turn it off if he or she likes.
Class B1 systems have labeled protection. This means that
security procedures and sensitivity labels are required for
each file. (A sensitivity level is basically a security
classification) Class B2 adds the requirement that the system must be
able to account for every code in the system. This helps to prevent
such security holes as Trojan horses. Class B3 deals with the
security of data access, in terms of prevent tampering and
notification of security-relevant events.
The most secure class, Class A1, requires verified designs.
Although they are functionallythe same as B3 systems, A1
systems have also been formally defined, as well as proven by
The set of files that contain the security privileges on an SCO UNIX
system is referred to as the Trusted Computing Base (TCB). It
consists of a database of information that is accessed by both
utilities and the SCO UNIX kernel to prevent unauthorized use of the
system. (Since you need a user account to get access, and TCB
privileges are determined by the user account, you can say that the
TCB also prevents unauthorized access.)
When implementing these security functions, an SCO UNIX system is
referred to as trusted rather than secure. A computer
system can never be completely secure, but by implementing these
features, it can be trusted to provided a specific amount of
SCO UNIX allows C2 security to be relaxed. Both trusted and relaxed
security use the TCB database. Both feature login security, command
restriction, and data encryption. A trusted system goes one step
further and audits the use of certain commands, logins and logouts,
database events, and use of authorization. It also allows
greater command restriction.
As I mentioned above, the C2 level of security allows the system
administrator to decide what should be protected and what not. This
is the concept of discretionary access control(DAC).
On traditional UNIX systems, this discretion is only in the form of
file permissions. (Who gets an account is also at the discretion of
the system administrator)
Under C2 security as implemented by SCO, this is expanded to include
authorizations and protected subsystems.
Authorizations are broken down into two categories: kernel and
sub-system. Sub-system authorizations (also called
privileges) are assigned to users to allow them to perform
various tasks on the system. For example, a user must have
authorization to stop or start the print scheduler.
Kernel authorizations are associated with processes. Although the
processes are acting on behalf of the users, there is a slight
difference in the effects it has on access. For example, certain
commands under SCO UNIX will change the UID temporarily as it's
running. These are called SUID programs as they set the uid.
Without the execsuid kernel authorization you cannot run such
a program even if the file permissions allow you to.
Protected subsystems are collections of files that provide common
functionality, access to which is normally controlled as a group not
as individual files. For example, administering printer consists of
accessing several different (but related) programs. Therefore, lp
is considered a protected sub-system.
Starting with SCO UNIX Version 3.2. Release 4.0, there are four
levels of security: low, traditional, improved and high. Each
offering more security than the one before it. During installation,
the level of security is one of the questions asked. As described
above, this determines the default access user's have to
Note that I said default. There are two things to keep in
mind. First, authorizations and access to protected sub-systems is on
a per user basis. Once they are set, the system defaults do
not affect them. Therefore, if you change the default and want
existing users changed, you must change them by hand.
The second thing is that you can use relax(ADM) to change to
any security level. However, you should only use it to change to a
less secure level. The reason for this is that you must then
change the access on all existing users to reflex the new level. It's
safe to think, for example that a system changed to traditional with
trusted level users is still traditional security. However, a system
with traditional security remains so, even if you "improve”
it to trusted. This is because there are still users with privileges
at the traditional security level.
The files that form the basis for system security reside in two
separate directories: /etc/auth
and /tcb. The
contains the system and sub-system related database files as well as
the system defaults.
The /tcb directory
contains binaries, libraries and user related database files.The
/tcb/bin directory contains the binaries that are used by both
the operating system and the system administrator to insure system
integrity and security. The more important ones we'll talk about in a
minute. The /tcb/lib
directory contains TCB library files
One of the key things to note is that although these directories
represent different perspectives (/etc/auth
is from a system perspective and
/tcb is from a user perspective), both directories contain
much of the same information. This is not a duplication of
effort, rather it provides a check to ensure that there is no
corruption in the database as well as making access to the data
Users can't look in the files, so understanding how these files are
laid out is of little use to them. Since the files are created
automatically, even system administrators rarely needs to look in
these files themselves. However, on those occasions where something
does go wrong with the TCB database (such as a user not having the
privileges he or she used to have), knowing what these files say can
be very useful. In addition, I feel that understanding what these
files contain and how they work together aids in understanding SCO's
implementation of system security.
System privileges allow users (user processes) to gain access
to specific operating system services. Most users are familiar with
the chown command, which
changes the ownership of the specified file. The chown
command makes use of the chown()
system call, which, in this case, is the operating system
service in question. Without the chown privilege, you cannot use the
chown()system call and
therefore cannot use the chown
command. Another commonly used service is accessed through programs
that are set-UID, that this, those that change the User-ID of the
process when they run. Without the execsuid privilege, you cannot run
SUID programs. Table 0.1 contains a list of the system privileges.
audit subsystem parameters
audit records to the audit trail
the set-UID and set-GID bit on files
the owner of an object
operating system auditing of the process
Table 0.1 System privileges
The TCB is actually composed of several different databases, each
related to a different aspect of the system. The Protected Subsystem
Database contains those files that are related to subsystem
authorizations. This database is broken down by subsystem
authorization, listing each user with that authorization. These files
are located in /etc/auth/subsystems.
This directory contains files whose names are the primary
subsystem authorization they represent. For example, the users with
the uucp authorization are in the file /etc/auth/subsystems/uucp.
Each file contains a list of users and what primary and
secondary authorizations each user has. If a user listed here,
but the privilege is not specified for that user in the Protected
Password Database security: (more on that in a moment),
then the database is inconsistent.
By dividing the authorizations in this way, the "powers"
that were once reserved only for the root user are now divided into
subsystems, enabling the system administrator to assign only the
privileges that each user should have. Secondary authorizations are
then used to limit these capabilities even further, if necessary.
Keep in mind two things. First, certain SCOAdmin managers require
more than one authorization. For example, to use the Filesystem
Manager you both need the sysadmin and backup authorizations.
Second, be careful of what privileges you assign. The auth subsystem
authorization allows users to make changes to any account, including
root. Other authorizations, such as backup, sysadmin, or passwd can
be similarly abused.
Let's take a look at one of these files. For example, the file
might look like this:
Each line begins with the name of a user who is to be given the
particular subsystem authorization. In this case, the primary
authorization is lp and the secondary authorizations are printqueue
and printerstat. Some users, such as lp and root are given just the
primary authorization. By giving a user just the primary
authorization, you give them all the secondary authorizations. In
this case, there are only the two secondary authorizations, so it
would have be sufficient to give those users the lp primary
So what's the difference? Well, in many cases, there is no secondary
authorizations, for example the mem authorization. However, where
there are secondary authorizations, you can further limit the access
each user has. In our example above, those user with just the
printqueue authorization are able to see everyone's print job,
without it they could only see there own. However, in order to enable
or disable printers, they need the printerstat authorization. Table 0.2
contains a list of primary authorizations and Table 0.3 contains a
list of the secondary authorizations. Where the secondary
authorizations are defined is /etc/auth/system/authorize.
The left side of this file in the primary authorization and
the right side is the corresponding secondary authorization(s).
system data tables (i.e. list all processes)
use of the write
use of cron, at
use of commands in /tcb/files/rootcmds
Table 0.2 Primary Authorizations
audit reports on one's own activities
(but not restore) backups
(but not create) backups
command to query disk space
jobs in queue using lpstat
to the root account and other accounts (still requires a
Shutdown Manager or shutdown
Table 0.3 Secondary Authorizations
The Terminal Control Database contains information about terminals
(both physical and pseudo that are used to login. This includes
information about who logged in last and whether or not the terminal
is locked. Two files compose the Terminal Control Database. The
contains entries for the terminals on the system. Each entry
describes characteristics a physical device, such as the name of the
device, the UID of the last user to login on this terminal and if the
terminal is locked. For a complete list of the characteristics, look
at the ttys(F) man-page.
file makes name assignments for different device names that
represent the same physical device. This is so that you don't need to
specify every device in /etc/auth/system/ttys.
The File Control Database contains a list of files and directories
along with their permissions, owner and group. This is contained
within the /etc/auth/system/files
file. The purpose of this database is to ensure that programs do not
grant more access than they should (for example, granting root
privileges through the SUID bit) and ensuring that data files can
only be accessed by the right users (such as ensuring that
/etc/passwd cannot be written to by everyone). Two support
programs are used to ensure the file match their entries in the File
Control Database: integrity and
fixmog. For details on the format, check out the files(F)
However, in /etc/auth/system/files,
many groups of files are listed only by the directory they are in. In
other words, every file in certain directories is expected to have
certain permissions. In most cases this was fine, however, in SCO
UNIX 3.2.2 , this wasn't and problems arose. SCO UNIX 126.96.36.199
corrected this as well as the problem that permissions didn't match
between the two (/etc/perms
The Protected Password Database contains the information related to
users on the system, such as their encrypted password and the
sub-system authorizations they have. The information here is used in
conjunction with the /etc/passwd
(or /etc/shadow) file and
the protected sub-system database. The user specific TCB database
files reside in /tcb/files/auth.
They include much more than the password. In this directory are 26
sub-directories, one for each letter of the alphabet. These letters
represent the first character of every login on the system. (Note
there are only 26, since a user account name cannot begin with a
number, a non-English character nor a capital letter) Within the
respective directories are files with the names of each user.
The files in these directories contain some information that is
stored elsewhere like the user name, UID and even the user's
encrypted password. The structure of these files is somewhat
difficult to understand at first. So we ought to take a quick look at
how these files are put together.
Reading TCB Files
Although it may not appear that way, each file contains only a single
line. At the end of each line is a backslash (\) which indicates that
the line continues. (Note that the backslash must not appear on the
last line) Each field is separated with a colon (:) and with the
exception of the user name at the very beginning, the entries can
appear in any order.
If lines are split in multiple virtual lines. Then both the last
entry on the first line by be followed by a colon as well as the
first entry on the next line must be preceded by one. The chkent
field indicates the end of that entry. For example:
could be split into:
These capabilities (or characteristics) can take one of three forms.
Capabilities requiring a string, are followed by an equal sign (=)
and then the string. Capabilities requiring a numeric value, are
followed by a pound-sing(#) and then the numeric value. Boolean
capabilities (those that are either on or off) are unchanged if on,
and followed by an at-sign (@) if off.
Let's take a look at what the entry for account looks like in the
Protected Password Database:
The first entry is my user name, 'jimmo'. However, so is the second
entry (u_name). At first
this appears like redundant information, however it does make things
easier when the system is reading this files to build it's internal
tables. The u_id is my
user ID as it appears in /etc/passwd.
Note the backslash, just after my UID. As I mentioned before, this
indicates that this is a single logical line, although it spans
multiple physical lines in the file.
The next entry (u_pwd) is
my encrypted password. As I mentioned before, If this system had a
low security level, then this will be the same as in /etc/passwd.
In all but the lowest security level, the encrypted password is not
stored in /etc/passwd, but
rather /etc/shadow. (For
more details see the shadow(ADM)
Think back to the problem of transferring files and mixing up the
UIDs. This is the place, along with the /etc/passwd
file, where you would make the changes. Afterwards run authck
to ensure the integrity of the TCB.
What kind of user I am is determined by the u_type
entry. Here, I am just your average user, which is referred to as
"general" in the TCB database. (Although this is referred
to as an "individual" user in the sysadmsh
if you have ODT 3.0). This is determined when the user is
first created. (Note that the descriptions here do not always match
the ones in the sysadmsh
in ODT 3.0 or the usermod
command in OpenServer)
The next few entries deal with your password. The u_succhg
is the last time you successfully changed your password. The
u_pswduser entry is who
can change my password. In this case I can. However, if root wanted
to keep me from changing the password, (for example if this account
was shared by several users) there would be some other user name
Next, we have records of my last logins. The entries u_suclog
and u_suctty say when and
on what tty the last time I successfully logged in. The entries
u_unsuclog and u_unsuctty
say when and on what tty the last time I unsuccessfully logged in.
The u_lock entry says
whether my account is locked or not. This could be the result of too
many unsuccessful attempts at logging in or the system administrator
thinks I work too hard and wants to keep me out. Because this is a
Boolean value and there has an '@', this means my account is not
locked. Finally, chkent
indicates the end of the entry. If you were paying attention, you'll
notice that I never once mentioned what privileges I have. In this
case, I didn't need to. When the user account jimmo was created, I
was given default system privileges. Therefore there is no
need to store this information here. Instead it's kept in
Should a user get created that has privileges other than the default,
all the privileges the user has are listed here. Not just the
ones that are different than the default. This is necessary for a
couple of reasons. First there are cases where a user has less than
the default. There is nothing built in to say the a user does not
have a particular privilege, that is, you are removing it from him.
You would therefore need another entry for those privileges that are
Second, there is no entry to say that the user has the default, other
than the fact there is nothing specifically listed. There could be a
specific entry to signify the user had the default, plus whatever
was listed. We could reference the user's entry in dflt_users.
However, this is not keeping with the separation of the files in
/etc/auth being system oriented and the files in
/tcb/files/auth being user
Should the privileges be listed here, there will be in the
u_cmdpriv and u_syspriv
entries. The u_cmdpriv
entry lists the subsystem authorizations the user is given and the
u_syspriv entry lists the
kernel authorizations the user is given.
Note that if no u_cmdpriv
or u_syspriv entries are
listed, this does not mean that the user has the default
privileges. This is a safety mechanism to ensure that the privileges
match. The file /etc/default/subsystems/dflt_users,
contains a list of users with default privileges. If there is either
a u_cmdpriv or u_syspriv
entry for a user that is listed in dflt_user,
the TCB database is considered inconsistent.
There are a dozen more entries that can find there way into the
protected password database files. Many are added depending on
changes made to the user account through the sysadmsh. Should you
have the SCO UNIX or SCO ODT Development System installed, you can
find a list of all the entries in /usr/include/prot.h.
If not, Table 0.4 contains a list of them.
The default nice value login
The minimum length of time before user's password can be
The maximum length of a generated password.
How long a password lasts until it expires.
How long after the password has expired until the account is
Can the user pick their own password? (Boolean)
Can the user use the password generator? (Boolean)
Should the user's password be checked for obviousness?
Is a user allowed to have a null password? (Boolean)
Maximum number of unsuccessful attempts to log in before
account is locked.
Is the account locked by default? (Boolean)
Can duplicated account information be inconsistent between
/etc/passwd and the Protected Password database?
Is TCB the master
for inconsistent fields? (Boolean)
Maximum significant length of cleartext passwords in units of 8
characters. If this is 1, then only the first 8 characters are
Maximum number of unsuccessful attempts to log in to a terminal
before locking the terminal.
This is the length of time (in seconds) to complete a
successful login before the login times out.
Table 0.4 Fields in /tcb/files/auth files
As I mentioned earlier, the entries in
/tcb/files/auth/* are user related. They correspond indirectly
to the files in /etc/auth/subsystem.
The u_cmdpriv entries
contain a list of the subsystem authorizations that user has. Simply
having them in these files is not enough. The files in
list details what user has what privilege, but from the privilege
perspective. These two must be consistent.
Issues with TCB Files
Up to this point we've talked about how the files interact and that
the TCB database is considered in "consistent" if the files
don't match. However, up until now I have intentionally left things a
little vague on correcting things as I wanted to talk about correct
problems all at once. Not just the individual files.
Even if the system was installed correctly and the TCB database files
were managed correctly, it is possible for the files within the
different TCB databases to become corrupt or inconsistent. This is
usually the result of abnormal events such as hardware fails or
system crashes. If this happens, the system does have built in a
mechanism to prevent inappropriate access.
This mechanism is the rule that if things are inconsistent, a user
gets the least amount of privilege possible. For example, let's
assumethe user jimmo was given backup subsystem privileges. This
means I have the secondary sub-system authorization "queryspace",
which means he can see how much disk space is being used. If
suddenly my name is removed from the Protected Subsystem Database
(the file /etc/auth/subsystems/backup)
I would loose this privilege although it was still in the protected
password database (/tcb/files/auth/j/jimmo).
What to do? Which is correct? How do you even know something is wrong
in the first place? The first way is that the user tells you. He or
she is happily doing his work when all of a sudden he can no longer
perform a task that they could a few minutes ago. There will usually
be some message about insufficient authorizations, which usually
tells you what's missing.
Well, the most obvious thing is to restore from backups. Using the
information I provided above you can see what sub-directories are
You then do a selective restore of those directories. Unfortunately,
time limitations may not always allow you to do this. Depending on
the speed of your tape drive and the type of backup you did, it may
be an hour or so before you are back to where you were. Fortunately,
SCO UNIX has some built-in tools that will check and correct most of
the problems you will encounter.
Assume you had a situation like we mentioned above, where the two
databases where inconsistent. You can use the program
/tcb/bin/authck (authentication check), which will check all
the database for consistency. There is a particular option to authck
to check each of the databases. However, you can check everything at
once with the -a option.
If you are concerned (or curious) about what changes are being made
you can use the v
(verbose) option, as well. This provides a "running diagnoses."
Because of the importance of having the databases consistent, this
system actually runs authck
each time the system goes into multi-user mode. Look at the
/etc/inittab file. One of
the first few lines starts with ack.
If you look at that line you see the program it runs is
is the program that actually runs authck.
(Check the inittab(F)
man-page and the chapter on Starting and Stopping Your System for
Next, look at /etc/authckrc,
which is just a simple shell script. About midway through the script
you will see the message:
This message is echoed to your screen just before authck
runs and indicates the first phase of checking the entire TCB
database. Here the authckrc
script runs /etc/tcbck,
which does a basic "sanity check" of the TCB database. It
looks for missing files as well as ones that might be in an invalid
state as the result of a crash of something else.
Towards the bottom of the
authckrc script you will see several lines that you may have
noticed when as the system is booting into multi-user mode:
Checking auth database ...
Checking protected subsystem
If you have ODT 3.0 and look in /etc/authckrc,
you will also see that just after the system echoes these messages,
it runs authck. This first
time with the -p option to check the protected password database and
the second time with the -s option to check the protected subsystem
database. In OpenServer, authck
is called once, with both the -p and -s options.
Just before it exits, you see authckrc
Checking ttys database ...
Just afterwards it runs /tcb/bin/ttyupd.
At first it surprised me that authckrc
just didn't run authck -t
to check it. Well, that's just the point. The -t option to authck
just checks the values in /etc/auth/system/ttys
for "reasonable" valued. However, it takes the /etc/ttyupd
program to correct problems.
A common problem that administrators run into with a lot of users on
their system is that fact that running authck
takes a long time. First, it is run with the
-p option then again with the -s
option. This means that for every user on the system authck
is run twice. (NOTE: This is only for ODT 3.0)
There are two ways around this. First you can create the file
/etc/default/security which contains the single line:
I don't recommend doing this, since it turns off all checking. That
is, authck is not run at
all. If the TCB database is corrupt, you may not notice it until too
late. Therefore, a good idea would be to edit authckrc and comment
out the two line running authck, then add a new one that runs authck
on all database. It would look like this:
(The -v option tells it to verbosity report things as it's making
Odds and Ends
The TCB is the primary mechanism for controlling system access,
despite the fact that it is permissions that allow users to run
programs and access files. The permissions on these programs remains
constant, regardless of what security level you have. However, the
privileges that a user has changes. It is for this reason that it is
essential that changes to the TCB be made with the appropriate tools
and not by editing the files directly, despite the what I showed you
how to do in the previous section.
/tcb - The Trusted Computing Base files.
/tcb/audittmp - Audit compaction file directory
/tcb/bin - TCB binary files
/tcb/files - Directory containing TCB related files
/tcb/files/audit - Directory containing files used when auditing is
/tcb/files/auditparams - Templates used for auditing
/tcb/files/initcondlog - Log file for init and getty events
/tcb/files/rootcmds - As root commands
/tcb/files/subsys - Used to authenticate an authorized which calls
/tcb/lib/ - TCB library files
/tcb/lib/auth_scripts - TCB scripts.
/etc/auth - System and subsystem authorizations
/etc/auth/dlvr_audit - Passes on audit information from a protected
/etc/auth/subsystems - Subsystem authorizations.
/etc/auth/subsystems/* - List of users given specified authorization
/etc/auth/subsystems/dflt_users - List of users authorized default
access to the subsystem.
/etc/auth/system - System/kernel authorizations.
/etc/auth/system/authorize - System authorizations.
/etc/auth/system/default - Current default TCB entry.