C. Controlling access to databases

C.1 Overview

GNATS supports granting various levels of access to the GNATS databases served by the network daemon, gnatsd.

GNATS access can be controlled at these levels:

deny

gnatsd closes the connection

none

no further access until userid and password given

listdb

only listing of available databases is allowed

view

query and view PRs with Confidential=no only

viewconf

query and view PRs with Confidential=yes

edit

full edit access

admin

full admin access

These access levels are used in the following settings:

• overall gnatsd access level
• overall access level set by host name or IP address
• overall access level set by userid and password
• per-database access level set by userid and password

C.2 Overall gnatsd access level

The overall gnatsd access level is set by starting gnatsd with the option

-m level or --maximum-access-level=level,

where level is one of the six access levels listed above. This restricts any access to the GNATS daemon to levels up to and including level, regardless of the settings in the access control files discussed below. If this option is left out, any access levels set in the access control files will be allowed.

The discussion below assumes that the pre-build configure of GNATS was done without altering the default values for the --enable-gnatsd-user-access-file and --enable-gnatsd-host-access-file options. If non-default values were given, substitute as appropriate below.

C.3 Overall access levels per host

The host access file (by default ‘/usr/local/etc/gnats/gnatsd.host_access’) controls overall access levels on a per-host basis, meaning that settings in this file apply across all databases on the server. Entries in this file are in the following format:

host:access-level:whatever

host is the hostname or IP address of the host contacting gnatsd. Wildcard characters are supported: ‘*’ matches anything; ‘?’ matches any single character. By using wildcards, you can specify access levels for entire network subnets and domains. Note that when GNATS authenticates hosts, it reads the entries in this file in sequence until a match is found. This means that wildcard entries must be placed near the end of the file, otherwise, they will override non-wildcard entries appearing after the wildcard ones.

The second field is the access level of host. The default is deny. If the user’s hostname isn’t in the file or its access level is set to deny, the connection is closed immediately.

GNATS currently doesn’t make use of the third field. Remember to still include the second ‘:’ on the line if you choose to leave the third field empty.

Whenever a CHDB command is processed (or defaulted), the user’s access level is set to the level for their host, as determined by the values in the ‘gnatsd.host_access’ file. However, even if a host is given the none access level, an individual can still give the USER command to possibly gain a higher (but never lower) access than is set for their host. The gnatsd USER command takes two arguments: USER <userid> <passwd>.

C.4 Access levels per user

Access levels per user can be set both across all databases on the server or on a per-database basis. The ‘gnatsd.user_access’ file in a database’s ‘gnats-adm’ directory specifies the user access rules for that database. If it doesn’t exist, or doesn’t contain the user name given to gnatsd, then the overall user access file (by default ‘/usr/local/etc/gnats/gnatsd.user_access’) specifying the per-user access levels across all the databases on the server is checked.

The user access files can only increase the access level defined in the host access files for the given host, they can never lower it.

If the access level is none after processing the userid and password, the connection is closed.

The ‘gnatsd.user_access’ files can contain plain text passwords, in such a case they should be owned by the GNATS user with file permission 600.

Wildcard characters are supported for the userid and password with plain text passwords. A null string or ‘*’ matches anything; ‘?’ matches any one character. Note that when GNATS authenticates users, it reads the entries in this file in sequence until a match is found. This means that wildcard entries must be placed near the end of the file, otherwise, they will override non-wildcard entries appearing after the wildcard ones.

Entries in the database-specific ‘gnatsd.user_access’ user access file in the ‘gnats-adm’ directory of the database have the following general format:

userid:password:access-level

The overall ‘gnatsd.user_access’ user access file adds a fourth databases field:

userid:password:access-level:databases

password should either be in plain text, DES crypt()(4) or MD5 hash format(5).

If the password is in plain text format, it must be prefixed by ‘$0$’ and if it is in MD5 format, it needs to be prefixed by the string ‘$1$’.(6) Passwords encrypted by crypt() should have no prefix. If no password is given then users can login with an empty password string.

A gnats-passwd tool to manage ‘gnatsd.user_access’ files is planned. In the meantime, crypt() passwords can be generated by using standard UNIX passwords tools, while MD5 passwords can be generated with the following little Perl snippet:

perl -e 'use Crypt::PasswdMD5 ; print Crypt::PasswdMD5::unix_md5_crypt
"password" , time() % 100000000'

If your Perl installation doesn’t have the Crypt module installed, you need to install it. On most systems, the following command achieves this:

perl -MCPAN -e 'install Crypt::PasswdMD5'

A tool for conversion of pre-version 4 ‘gnatsd.user_access’ files is distributed with GNATS 4. See section Converting old password files.

The access-level field should contain one of the values listed at the beginning of this appendix. This overrides (increases but never lowers) the access level given as the default for the user’s host in the global gnatsd.host_access file.

The following shows an example ‘gnatsd.user_access’ file with plain text passwords:

rickm:$0$ruckm:edit
pablo:$0$pueblo:view
*::none

And this is the same file with MD5-encrypted passwords:

rickm:$1$92388613$D7ZIYikzTUqd./dODTFrI.:edit
pablo:$1$92388652$QRfAhIBG5elT.FQjQKhj80:view
*::none

In these examples, anybody other than rickm and pablo get denied access, assuming that the host access level is also none. You could set the catch-all rule at the end to be *::view to allow view access to anyone who does not supply a password. Note the important detail that such a rule would allow view access only to persons who do not supply a password at all, i.e. if rickm or pablo tries to log in but mistypes his password, this rule would not apply and they would be denied access entirely. This is by design, since people might be surprised if they suddenly found themselves logged in, but with a lower access level than they usually have.

The databases field contains a comma-separated list of database names, as defined in the ‘databases’ file (see section The databases file. Wildcard characters are supported. The databases listed in this field are the ones to which the other settings on the same line will be applied.

C.5 Privileged gnatsd commands

Every gnatsd command has a minimum access level attached to it. If your access level is too low for a command, you get this response:

  LOCK 12
  422 You are not authorized to perform this operation (LOCK).

The commands CHDB, USER and QUIT are unrestricted.

The DBLS command requires at least listdb access.

A user must have at least edit access for these commands:

LKDB

lock the main GNATS database.

UNDB

unlock the main GNATS database.

LOCK PR user pid

lock PR for user and optional pid and return PR text.

UNLK PR

unlock PR.

EDIT PR

check in edited PR.

APPN PR field, REPL PR field

Appends to or replaces the contents of field in PR.

The DELETE PR command is special in that it requires admin access.

All other commands require view access.

edit-pr and query-pr accept the command line arguments -v|--user and -w|--passwd. See section The GNATS User Tools.

This document was generated by Chad Walstrom on March 3, 2015 using texi2html 1.82.