Description of problem: The User Guide security section goes into great detail on features that are less used while missing very basic settings that will allow an administrator to set up a simple Grid. Instead of making things more understandable it seems to make it more complex. Now where does it explain and example to set the ALLOW macros to ensure an execute node will be able to execute jobs. There is an example in the condor manual that is let out. PErhaps it is too detailed but something like it needs to be included. Example from Condor Manual: ALLOW_READ = *@cs.wisc.edu/* ALLOW_WRITE = *@cs.wisc.edu/*.cs.wisc.edu ALLOW_ADMINISTRATOR = condor-admin.edu/*.cs.wisc.edu ALLOW_CONFIG = condor-admin.edu/*.cs.wisc.edu ALLOW_NEGOTIATOR = condor.edu/condor.cs.wisc.edu, \ condor.edu/condor2.cs.wisc.edu ALLOW_DAEMON = condor.edu/*.cs.wisc.edu # Clear out any old-style HOSTALLOW settings: HOSTALLOW_READ = HOSTALLOW_WRITE = HOSTALLOW_DAEMON = HOSTALLOW_NEGOTIATOR = HOSTALLOW_ADMINISTRATOR = HOSTALLOW_OWNER = A paragraph follows that explains the settings above. I'm not saying this is the best example. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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