Account creation permission criteria
Currently, RATS verifies
if a user is allowed to create a given account type by checking a number
of proprieties against the
PDB. The current propriety types are roster, roles, campus location,
and major. However the current configuration options do not allow
for exclusion of certain proprieties. In technical terms we support "OR"
and "AND" but not a "NOT". We intend to add this functionality.
An important result of this
functionality would be the ability to create lists of users for which you
do not allow account creation
of disciplinary or other reasons. One possible way of supporting this,
would be a creation of a host specific HERD of "bad" users which would
be added in the list of exclusions for an account type
In addition, some
of the criteria will be broadened. For example, the current roster selection
is based on the section registration
ID (i.e.: 34535) , which means that an account type for a class with
a large number of sections may require a complex configuration. In RATS
version two a new API call to the PDB will be added to support a user to
roster check based on the ID of the class alone (i.e.: 01:744:444).
One other possible improvement,
which we are not yet committing to, is the collapse of the 4 different
criteria into one single one, supporting tag values and logical relationships.
Improved account cleanup
Currently RATS V1 allows
for the addition of many account types to one user on one host. Unfortunately
the only removal process supported is that of whole UNIX account at once.
This is obviously non-optimal as account types may need to be added and
removed to illustrate changes in functions and responsibilities. However,
in RATS V1, no information was stored about what account types have been
applied to a user. As of, RATS V2, this information will be stored in the
local DB, and the ability to remove only the proprieties associated with
one account type will be added. It is still unclear if this feature will
be supported for the flat file operation mode of RATS V2, as it would require
the addition of yet another flat file to maintain, lock, and generally
fret about. The RATS design team would appreciate input on this subject.
The functionality described
will be added the existing ratsadmin tool which will now require an account
type for the removal
mode as well, or a flag which would trigger the removal of all account
types and the UNIX account itself.
Inetd Support
On a smaller host, the ratsd
client daemon may pose a load burden not justified by the low usage rate.
Further more, as of yet
unknown bugs or conditions failures may crash the running daemon and
create service outages for larger systems. For both of these reasons, we
intend to expand the ratsd capabilities to being spawned from the standard
UNIX inetd facility as well as maintaining the current stand-alone mode.
Just as with the current RATS implementation, the "-d" switch will place
ratsd in daemon mode. However, while currently running ratsd without the
"-d" option only prevents it from self backgrounding, in RATS V2 this will
place ratsd in "inetd" mode and indicate that no port listen should be
performed and that STDIN should be treated as the network stream.