[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

D. Controlling access to databases

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
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 (not currently used)

There are three main features:

 
- security by obscurity, defined in the next paragraph
- access level set by host name or IP address
- access level set by userid and password

gnatsd has parameters -r or --require-db. If so executed, nobody gets in unless they are able to ask for a database by alias name with the CHDB (change database) command. If you specify an incorrect database alias the connection is closed. Only the CHDB command is allowed, and you just get one try.

The second field of the `gnats-adm/gnatsd.conf' file is the access level for the user's host. The default is edit to be compatible with previous releases of gnats. If the user's hostname isn't in the `gnatsd.conf' file or its access level is deny, the connection is closed immediately.

Whenever a CHDB command is processed (or defaulted), the user's access level is set to the level for their host.

Even if a host is given the none access, 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>.

An optional file `gnats-adm/gnatsd.access' specifies the user access rules. If it doesn't exist, or doesn't contain the user name given to gnatsd, then `/etc/gnatsd.access' is also checked. This filename is set in `config.c' at compile time.

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

The `gnatsd.access' file is clear text, but it is installed to be owned by the GNATS user with file permission 600.

Wildcard characters are supported for the userid and password. A null string or "*" matches anything; "?" matches any one character.

A `gnatsd.access' file might look like this:

 
# field 1: user
# field 2: passwd
# field 3: access   (valid entries: deny, none, view, viewconf, edit, admin)
# field 4: database (/etc/gnatsd.access only; ignored in gnatsd-adm)
rickm:ruckm:edit:*
pablo:pueblo:view:*
*:*:none

In this example, 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.

The fourth field is a comma-separated list of database aliases to match alias entries from the second field of the database file `/etc/gnats-db.conf'. Wildcard characters are supported. This field is only used in `/etc/gnatsd.access'. It's ignored in `gnatsd-adm/gnatsd.access' since this file is already database specific.

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 rickm
  520 You are not authorized to perform this operation (LOCK).

These commands, along with all of the query constraint setting commands (PRIO, SYNP, etc) are unrestricted: HELO, QUIT, AUTH, USER, CHDB and VDAT.

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>

All other commands require view access.

The DBLS and DBLA commands (list databases and aliases) require view access but still only list databases to which the user's host has at least none access. A user might have view access on one database and be able to list the other database names, but upon executing CHDB find that they have none access to the second database and not be able to execute anything other than another CHDB.

nedit-pr, npr-edit, nquery-pr and sub-type all have the command line args -v|--user and -w|--passwd. gnatsd only accepts database alias names for the -d|--directory arg from these commands (not full database pathnames). Local clients (query-pr, mkcat, etc) accept either.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]