2.2 Managing Greenpass

2.2.1 User Information Storage

  1. gpInfo

    Greenpass keeps a text file for every user in the system. The files are store as sexp dumps in the gpradsrc/gpInfo directory. These files allow persistance of permissions accross server restarts. All the files in the directory are automatically loaded on startup.

  2. Dynamic Map

    Greenpass keeps an internal map of users in memory. The map in memory is user to confirm or deny a users permissions.

  3. Synchronization

    Greenpass has three commands related to keeping the file and dynamic maps in sync:

    Information on running these commands can be found below, in section 2.2.2 adminAuthServer.sh

  4. Logging

    Greenpass by default generates a log file in $GREENPASS_HOME/gpradsrc/jdaemons/AuthServer.log. This location and the amount of information logged can be changed by updating flags in the startauthserver.sh script.

2.2.2 adminAuthServer.sh

A simple script to make working with the JDSIAuthServer easier. $GREENPASS_HOME/gpradsrc/scripts/adminAuthServer.sh sends commands to a running instance (via the listening port) and reports outcomes. The arguments needed for use change depending on the command.

2.2.2.1 Command List

2.2.3 Listing Users

2.2.3.1 Public Keys vs Names

User information is stored under the public key, since that is the certain link to the user. Since cryptographic keys are hard to use, Greenpass allows (and encourages) delegators to enter label text to usefully identify guests. When viewing the list of users, the public key and label text info (if any) is displayed. Only the public key information should be considered at all reliable or verified; Greenpass makes no assertions about the validity of certificates or text info associated with any keypair.

2.2.3.2 Relationships

Each delegated user in Greenpass has one or more Ancestors or Children, tracing all the way back to the SOA, who have delegated access. For example, Alice the Admin is a bootstrapped user. Alice delegates access to Bob the department head. Bob delegates access to Charlie the guest professor. Charlies ancestors are Bob and Alice. Example output: 

# ./adminAuthServer.sh display e4daf9fb8fb2221291a933a2f3e61754
Setting command to display
------------------------------------
User=e4daf9fb8fb2221291a933a2f3e61754
        Label info:Charlie
        Expiration:2006/5/7
        Propogation:P:Y
Status=UNAUTHORIZED: EXPIRED
Users parents:
+Alice     2006/3/30       406a1c222aae4fbcedb5ac2025790d7b
+Bob       2006/3/30       45954bd5ff83fe219094d1dc1d94fa8b
Certs authorized by user:
        -Doug     2006/3/9        cc67ac5c65950ae720156d323bc19b24        P:N
        -Dave     2006/3/9        66c6b4d6fb449dfcbb211c0b0c9eff94        P:N
------------------------------------
Shows the information for Charlie, who was delegated to by Bob, and has delegated to Doug and Dave. Alice is the root level certificate. 
#./adminAuthServer.sh display 406a1c222aae4fbcedb5ac2025790d7b
Setting command to display
------------------------------------
User=406a1c222aae4fbcedb5ac2025790d7b
        Label info:Alice
        Expiration:2006/4/6
        Propogation:P:Y
Status=UNAUTHORIZED: EXPIRED
Root level certificate; authorized by the source of authority.
Certs authorized by user:
        -Bob     2006/4/6        45954bd5ff83fe219094d1dc1d94fa8b        P:Y
        -Bill    2006/4/6        4830741acbc2e6c3052a45262bb2b365        P:Y
        -Beth    2006/4/6        aeb28312d125a85e2e97e244d239dde8        P:Y
------------------------------------
Alice was bootstrapped, with permission directly from the SOA keypair.

2.2.3.3 Expiration

Authorizations are for a given period. A certificate past it authorization may not be used to log on to the Greenpass system. Expired certificate are not removed from the cache automatically; it may be necessary to do so by hand if the system begins to become slow.

2.2.3 Removing Users

To remove an authorization from the system, remove the file from the gpInfo directory, then reloadMapFromStore. The user associated with the key will be unauthorized, as will all the authorizations granted by the user.

2.2.4 Logging Options

File vs stdout

The AuthServer can report output to standard output, a log file, or both. The startauthserver.sh script sends output to a log file, gpradsrc/jdaemons/AuthServer.log, within the GREENPASS_HOME directory specified in setenv.sh Use the -f option when starting the authserver from the command line, or edit startauthserver.sh.

Log Levels

The AuthServer supports multiple levels of logging information:
  1. LOG: the most information; used for debugging
  2. WARNING: report any items that are unusual, but not problems.
  3. ERROR: report problems that may impact proper functioning of the system
  4. FATAL: report problems that may cause immediate harm; the system may be in the process of crashing.

2.2.5 Shutting Down

While JDSIAuthServer tries to make sure all the authorizations are stored in the gpInfo directory, the protections against lost information on a crash or unexpected shutdown are poor. Ideally, the system is shut down using the shutDownServer command, allowing it to gracefully write out log and authorization information.

Return to Main
1 Building Greenpass 2 Running Greenpass


Last edited August 14, 2006
Greenpass Home