Description of problem: - Expand overview to relate "access levels" to "authorization" in overview - Order subsections the same as concepts are introduced in overview, and how they are referenced, e.g. authentication before authorization because that is the order they are introduced and authorization refers to details of authentication 3.1. Access Levels - Strike "Access Levels" header under the chapter header - Config refers to condor_config.root, which does not exist anymore (I believe this is logged in another BZ as well) Table 3.1. Registered Commands - I'm confused by "The command that initiates a new negotiation cycle" - I believe this is resolved by using my table though. - How do we map the information from the table onto actual configuration? Suggest changing "Access level required" to Context as that's the correct security jargon here, and moving the table into an appendix that is referenced throughout the chapter. These security contexts can be used in the more restrictive security context (authentication, integrity, etc) as well as the Host-Based security (which is the type we ship by default). This table is really meant as a reference to ease the understanding of the type of security context needed for a certain task. It is important we keep the jargon the same, as the format we tell users to use in 3.2 is SEC_CONTEXT_FEATURE, and the table is providing the type of CONTEXT for given activities. There needs to be better wording to clarify what the table is representing in the overall security configuration. Also, the table needs to be updated to the one I provided earlier. 3.2. Security negotiation - Concept needs introduction in the overview - "Negotiation is performed by the condor_negotiator service" - incorrect as negotiation happens between any client and service when a connection is made - Need link between Access Levels and /CONTEXT/ or use common vernacular throughout. I suggest using context. - DEFAULT concept introduced but not explained. From the condor manual "The DEFAULT value for <context> provides a way to set a policy for all access levels (READ, WRITE, etc.) that do not have a specific configuration variable defined" Table 3.2. Security negotiation resolution - Left column appears to be first row, needs fixing Table 3.3. Security features negotiation resolution - Left column appears to be first row, needs fixing 3.3. Authentication - Needs overview (see condor manual) - "cmmunication" - "acces" - "The possible methods are" described in the next section. - awkward to list them twice so close together. 3.4. Authentication methods - Need link between "Windows"" and NTSSAPI - Generally need linkage between type here and from previous section, e.g. Filesystem = FS SSL - Needs to expand with an example (example for setting up a Certificate Authority for use with SSL provided in earlier BZ, but here it is again: http://pages.cs.wisc.edu/~zmiller/ca-howto/) Password - "onyl" - "servies" - "CONFIG-LEVEL" ? Think this should be <CONFIG>-level or some such. Filesystem - "srvice" - No mention of FS_REMOTE (File System Remote) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(In reply to comment #0) > Description of problem: > - Expand overview to relate "access levels" to "authorization" in overview > - Order subsections the same as concepts are introduced in overview, and how > they are referenced, e.g. authentication before authorization because that is > the order they are introduced and authorization refers to details of > authentication Good idea, but restructuring will have to happen later. Created BZ #633503. > > 3.1. Access Levels > - Strike "Access Levels" header under the chapter header Fixed. > - Config refers to condor_config.root, which does not exist anymore (I > believe this is logged in another BZ as well) <varlistentry> <term><parameter>CONFIG</parameter></term> <listitem> <para> Provides access to modify the configuration of services using <command>condor_config_val</command>. By default, this level of access can change any configuration parameters of a Condor pool. The <parameter>CONFIG</parameter> access level implies <parameter>READ</parameter> access. </para> </listitem> </varlistentry> When I find the other BZ, I'll mark it as a dupe. > > Table 3.1. Registered Commands > - I'm confused by "The command that initiates a new negotiation cycle" - I > believe this is resolved by using my table though. Your table is now in there. > - How do we map the information from the table onto actual configuration? > Suggest changing "Access level required" to Context as that's the correct <thead> <row> <entry> Activity </entry> <entry> Service </entry> <entry> Security Context </entry> </row> </thead> > security jargon here, and moving the table into an appendix that is referenced > throughout the chapter. These security contexts can be used in the more > restrictive security context (authentication, integrity, etc) as well as the > Host-Based security (which is the type we ship by default). This table is > really meant as a reference to ease the understanding of the type of security > context needed for a certain task. It is important we keep the jargon the > same, as the format we tell users to use in 3.2 is SEC_CONTEXT_FEATURE, and the > table is providing the type of CONTEXT for given activities. There needs to be > better wording to clarify what the table is representing in the overall > security configuration. I'll restructure this for 1.4. Added to BZ #633503. > > Also, the table needs to be updated to the one I provided earlier. This was done in BZ #618389. > > 3.2. Security negotiation > - Concept needs introduction in the overview > - "Negotiation is performed by the condor_negotiator service" - incorrect as > negotiation happens between any client and service when a connection is made > - Need link between Access Levels and /CONTEXT/ or use common vernacular > throughout. I suggest using context. > - DEFAULT concept introduced but not explained. From the condor manual "The > DEFAULT value for <context> provides a way to set a policy for all access > levels (READ, WRITE, etc.) that do not have a specific configuration variable > defined" Added to BZ #633503 > > Table 3.2. Security negotiation resolution > - Left column appears to be first row, needs fixing > > Table 3.3. Security features negotiation resolution > - Left column appears to be first row, needs fixing It should be rendering OK now. > > 3.3. Authentication > - Needs overview (see condor manual) Added to BZ #633503 > - "cmmunication" Fixed. > - "acces" Fixed. > - "The possible methods are" described in the next section. - awkward to list > them twice so close together. Deleted the first list. > > 3.4. Authentication methods > - Need link between "Windows"" and NTSSAPI > - Generally need linkage between type here and from previous section, e.g. > Filesystem = FS > SSL > - Needs to expand with an example (example for setting up a Certificate > Authority for use with SSL provided in earlier BZ, but here it is again: > http://pages.cs.wisc.edu/~zmiller/ca-howto/) Added to BZ #633503 > > Password > - "onyl" Fixed. > - "servies" Fixed. > - "CONFIG-LEVEL" ? Think this should be <CONFIG>-level or some such. <para> Storing a pool password requires <parameter><replaceable>CONFIG</replaceable>-LEVEL</parameter> access. The pool password can be set remotely, but this method is only recommended if it takes place using an encrypted channel. </para> > > Filesystem > - "srvice" Fixed. So many typos :( > > - No mention of FS_REMOTE (File System Remote) There's some mention of FS_REMOTE in the sections that haven't been completed yet, which will happen after 1.3. Sorry. LKB
(In reply to comment #1) > > 3.2. Security negotiation > > - Concept needs introduction in the overview > > - "Negotiation is performed by the condor_negotiator service" - incorrect as > > negotiation happens between any client and service when a connection is made This clarification needs to be addressed in 1.3. > > - Need link between Access Levels and /CONTEXT/ or use common vernacular > > throughout. I suggest using context. > > - DEFAULT concept introduced but not explained. From the condor manual "The > > DEFAULT value for <context> provides a way to set a policy for all access > > levels (READ, WRITE, etc.) that do not have a specific configuration variable > > defined" We need to at least give a small blurb about DEFAULT security since we do reference it. > > > > Table 3.2. Security negotiation resolution > > - Left column appears to be first row, needs fixing > > > > Table 3.3. Security features negotiation resolution > > - Left column appears to be first row, needs fixing > > It should be rendering OK now. Both still look the same. Possible staging isn't updated? > > > > 3.4. Authentication methods > > - Need link between "Windows"" and NTSSAPI > > - Generally need linkage between type here and from previous section, e.g. > > Filesystem = FS > > SSL > > - Needs to expand with an example (example for setting up a Certificate > > Authority for use with SSL provided in earlier BZ, but here it is again: > > http://pages.cs.wisc.edu/~zmiller/ca-howto/) > > Added to BZ #633503 This really needs to be addressed for 1.3 as well. We need to provide linkage between the previous section and what the authentication types are. > > - "CONFIG-LEVEL" ? Think this should be <CONFIG>-level or some such. > > <para> > Storing a pool password requires > <parameter><replaceable>CONFIG</replaceable>-LEVEL</parameter> access. The pool > password can be set remotely, but this method is only recommended if it takes > place using an encrypted channel. > </para> This is still coming out as: CONFIG-LEVEL, only all in italics. Staging not updated for some reason? > > > > - No mention of FS_REMOTE (File System Remote) > > There's some mention of FS_REMOTE in the sections that haven't been completed > yet, which will happen after 1.3. Sorry. > > LKB
Revision 6.19 should be on the stage now. LKB
Issues from Comment #2 still remain.
(In reply to comment #2) > (In reply to comment #1) > > > 3.2. Security negotiation > > > - Concept needs introduction in the overview > > > - "Negotiation is performed by the condor_negotiator service" - incorrect as > > > negotiation happens between any client and service when a connection is made > > This clarification needs to be addressed in 1.3. <para> Security settings are determined through a security negotiation process. Security negotiation is used to determine what security features are required for each connection: authentication, encryption, integrity checking, or a combination. Negotiation also defines which protocol to use for each feature. </para> > > > > - Need link between Access Levels and /CONTEXT/ or use common vernacular > > > throughout. I suggest using context. Changed instances of access level to context. > > > - DEFAULT concept introduced but not explained. From the condor manual "The > > > DEFAULT value for <context> provides a way to set a policy for all access > > > levels (READ, WRITE, etc.) that do not have a specific configuration variable > > > defined" > > We need to at least give a small blurb about DEFAULT security since we do > reference it. <listitem> <para> <parameter>DEFAULT</parameter> </para> <para> The <parameter>DEFAULT</parameter> value provides a way to set a policy for all access levels that do not have a specific configuration variable defined. </para> </listitem> > > > > > > > Table 3.2. Security negotiation resolution > > > - Left column appears to be first row, needs fixing > > > > > > Table 3.3. Security features negotiation resolution > > > - Left column appears to be first row, needs fixing > > > > It should be rendering OK now. > > Both still look the same. Possible staging isn't updated? It looks OK to me. What specific errors are you seeing? I know it's not pretty, but everything is in the right place. We need to come up with a different way to present this information. I've requested a graphic that we can drop in to the book post 1.3: https://engineering.redhat.com/rt3/Ticket/Display.html?id=73239 > > > > > > > 3.4. Authentication methods > > > - Need link between "Windows"" and NTSSAPI > > > - Generally need linkage between type here and from previous section, e.g. > > > Filesystem = FS > > > SSL > > > - Needs to expand with an example (example for setting up a Certificate > > > Authority for use with SSL provided in earlier BZ, but here it is again: > > > http://pages.cs.wisc.edu/~zmiller/ca-howto/) > > > > Added to BZ #633503 > > This really needs to be addressed for 1.3 as well. We need to provide linkage > between the previous section and what the authentication types are. I understand this, but time is short. We'll get it in as soon after 1.3 as we can. Unless you have a quick one or two sentences I can drop in now? > > > > - "CONFIG-LEVEL" ? Think this should be <CONFIG>-level or some such. > > > > <para> > > Storing a pool password requires > > <parameter><replaceable>CONFIG</replaceable>-LEVEL</parameter> access. The pool > > password can be set remotely, but this method is only recommended if it takes > > place using an encrypted channel. > > </para> > > This is still coming out as: CONFIG-LEVEL, only all in italics. Staging not > updated for some reason? The original XML looks like this: <parameter><replaceable>CONFIG</replaceable>-LEVEL</parameter> Which, it seems, the CSS is rendering as all in italics. I've changed this instance to: <command><replaceable>CONFIG</replaceable>-LEVEL</command> which should hopefully change the rendering. LKB
Rob, are you going to give Lana "a quick one or two sentences I can drop in now?" from the previous comment or shall we verify this one as is?
The remaining comments have been addressed via irc yesterday (9/20). The FS_REMOTE is now documented, as well as linkage between the auth methods and condor's configuration terms. My review of those changes has produced the following changes: Remote Filesystem - Remove " This authentication method is only appropriate for clients and services that are on the same physical computer." "the CONFIGsecurity context" - Need space between CONFIG and security
(In reply to comment #7) > The remaining comments have been addressed via irc yesterday (9/20). The > FS_REMOTE is now documented, as well as linkage between the auth methods and > condor's configuration terms. My review of those changes has produced the > following changes: > > > Remote Filesystem - Remove " This authentication method is only appropriate for > clients and services that are on the same physical computer." Gone. > > "the CONFIGsecurity context" - Need space between CONFIG and security <para> To store a pool password, the <parameter><replaceable>CONFIG</replaceable></parameter> security context is required. The pool password can be set remotely, but this method is only recommended if it takes place using an encrypted channel. </para> Look for version 6.22. Coming to a stage near you within the hour. LKB