Bug 640868

Please provide a better example if you prefer. Otherwise, we can add the one given above.

LKB

Pushing to 2.1 due to time & resource constraints and outstanding needinfo for example.

Deadline for this needinfo set to 30 June 2011 due to its inclusion in the 2.1
release. May change pending planning deadlines for MRG 2.1.

Please have one of the security guys look at this. Perhaps Pete?

What's missing is a distilled version of the 3.6.7 Authorization section from the condor manual (http://www.cs.wisc.edu/condor/manual/v7.6/3_6Security.html#sec:Security-Authorization).  This needs to be inserted before the current 3.1 Security Contexts section (so make this new section 3.1).  Should also include some of the examples, especially the various value allows for ALLOW_ parameters.

Yea!! +1 that is what's missing and as Robert said it needs to be before 3.1 and move everything down.

My first pass at content for the section:

3.1 Authorization
Authorization protects resource usage by granting or denying access requests made to the resources. It defines who is allowed to do what.

Authorization can be defined gradually, in terms of hosts, or fine grained in terms of users.  The configuration parameters define a set of users that will be allowed to (or denied from) carrying out various Condor commands. Each access level may have its own list of authorized users. A complete list of the authorization parameters:

    ALLOW_READ
    ALLOW_WRITE
    ALLOW_ADMINISTRATOR
    ALLOW_CONFIG
    ALLOW_SOAP
    ALLOW_OWNER
    ALLOW_NEGOTIATOR
    ALLOW_DAEMON
    DENY_READ
    DENY_WRITE
    DENY_ADMINISTRATOR
    DENY_SOAP
    DENY_CONFIG
    DENY_OWNER
    DENY_NEGOTIATOR
    DENY_DAEMON

In addition, the following are used to control authorization of specific types of Condor daemons when advertising themselves to the pool. If unspecified, these default to the broader ALLOW_DAEMON and DENY_DAEMON settings.

    ALLOW_ADVERTISE_MASTER
    ALLOW_ADVERTISE_STARTD
    ALLOW_ADVERTISE_SCHEDD
    DENY_ADVERTISE_MASTER
    DENY_ADVERTISE_STARTD
    DENY_ADVERTISE_SCHEDD

Each client side of a connection may also specify its own list of trusted servers. This is done using the following settings.

  ALLOW_CLIENT
  DENY_CLIENT

The names ALLOW_CLIENT and DENY_CLIENT should be thought of as `when I am acting as a client, these are the servers I allow or deny.'

All authorization settings are defined by a comma-separated list of fully qualified users. Each fully qualified user is described using the following format:

    username@domain/hostname

The information to the left of the slash character describes a user within a domain. The information to the right of the slash character describes one or more machines from which the user would be issuing a command. This host name may take the form of either a fully qualified host name of the form

host.example.com

or an IP address of the form

10.1.1.1

Within the format, wild card characters (the asterisk, *) are allowed. The use of wild cards is limited to one wild card on either side of the slash character. A wild card character used in the host name is further limited to come at the beginning of a fully qualified host name or at the end of an IP address. For example,

*@userdomain/host.example.com

refers to any user that comes from userdomain, where the command is originating from the machine host.example.com. Another valid example,

user@userdomain/*.example.com

refers to commands coming from any machine within the userdomain domain, and issued by user.

If the set of machines is specified by an IP address, then further specification using a netmask identifies a physical set (subnet) of machines. This physical set of machines is specified using the form

network/netmask

This flexible set of configuration parameters could define conflicting authorization. The following precedence rules are used to resolve these conflicts.

    1. DENY_* parameters take precedence over ALLOW_* parameters where there is a conflict. This implies that if a specific user is both denied and granted authorization, the conflict is resolved by denying access. 
    2. If parameters are omitted, the default behavior is to grant authorization for every user.

Perhaps a full explicit example. e.g. ALLOW_READ = myname
and/or ALLOW_WRITE = *.mydomain.com