Project

General

Profile

Bug #11087

File content (key/value format) technique allows white space before separator but not after it

Added by Hamlyn Mootoo 5 months ago. Updated about 1 month ago.

Status:
Released
Priority:
N/A
Category:
Techniques
Target version:
Target version (plugin):
Severity:
Major - prevents use of part of Rudder | no simple workaround
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Very Small
Priority:
65

Description

It seems that a directive created from the File content(key/value format) allows any amount of space and tab characters after the keyword and BEFORE the separator but not after it, or else it considers it non-compliant. For example:

If the keyword is COLOR, the separator is an equals sign (=), and the value is BLUE, then we have:

\t=tab character

COLOR=BLUE (result compliant)
COLOR =BLUE (result compliant)
COLOR =BLUE (result compliant)
COLOR\t=BLUE (result compliant)
COLOR\t =BLUE (result compliant)
COLOR\t \t=BLUE (result compliant)
COLOR \t =BLUE (result compliant)
COLOR \t=BLUE (result compliant)

COLOR= BLUE (result non-compliant)
COLOR= BLUE (result non-compliant)
COLOR=\tBLUE (result non-compliant)
COLOR= \tBLUE (result non-compliant)
COLOR=\t BLUE (result non-compliant)
COLOR=\t \tBLUE (result non-compliant)
COLOR= \t BLUE (result non-compliant)

Basically, any whitespace between the separator and the value causes the key/value pair to be considered non matching.

This is also true when the separator itself is a space as in the use of the variable ${ncf_const.s}

This makes it very difficult to determine whether a key/value pair is already compliant from an audit perspective, since the amount of whitespace before and after the separator doesn't matter for a lot of config files in linux, and is considered valid.

In some cases however, I could see that for some files, any whitespace before or after the separator should be considered non-compliant.

As a suggestion, you could add a checkbox to indicate a STRICT match (that is no whitespace allowed on either side), that would override a reasonable default of any amount of whitespace allowed on either side of the separator (especially when the separator itself is a space character).


Subtasks

Bug #11371: Add missing tests in branch 4.1 for parent ticketReleasedAlexis MOUSSET


Related issues

Related to ncf - User story #11346: Create a new generic method to set key/value with option to define if it is strict or not Released

Associated revisions

Revision 5c2c605b
Added by Nicolas CHARLES 3 months ago

Refs #11087: Creation of manageKeyValueFile version 1.1 from 1.0

Revision 96c47ada
Added by Nicolas CHARLES 3 months ago

Fixes #11087: File content (key/value format) technique allows white space before separator but not after it

History

#1 Updated by Alexis MOUSSET 5 months ago

  • Subject changed from File content (key/value format) technique allows white space before separator but not after it. to File content (key/value format) technique allows white space before separator but not after it
  • Category changed from Agent to Techniques
  • Target version set to 3.1.22

#2 Updated by Hamlyn Mootoo 5 months ago

As an example, the specific issue I was trying to resolve is to determine whether certain keywords in /etc/login.defs have the correct values.

For example, the following parameters defined in the file would all fail compliance even if the numerical values for each keyword in the rudder directive were identical.

PASS_MAX_DAYS 180
PASS_MIN_DAYS 1
PASS_MIN_LEN 8
PASS_WARN_AGE 7

The reason for this is the variable number of spaces between the keyword and the value, when using ${ncf_const.s} as the separator.

#3 Updated by Hamlyn Mootoo 5 months ago

Sorry, the example above seems incorrect because it collapsed multiple spaces. Let me try this again:

PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_MIN_LEN    8
PASS_WARN_AGE   7

#4 Updated by Nicolas CHARLES 5 months ago

  • Effort required set to Small
  • Priority changed from 52 to 55

Hi Hamlyn,

Thanks for this bug reports - there's indeed a surprising behaviour in this technique
Technique uses file_ensure_key_value generic method to edit the file, and this generic method edit file using ncf_maintain_keys_values
This last bundle looks in the file for lines starting with key\s*separator\s*, and if it find them, will replace the line by key\s*separatorvalue (so stripping last par of spaces)

Your suggestion to add a parameter looks sensible, and when we allow non strict match of spaces, then we should check for existance of "\s*${ke[${index}]}\s*${sep}\s*${${v}[${index}]}", and if it's there, don't do anything

#5 Updated by Hamlyn Mootoo 5 months ago

Yes the spacing in that regex seems to be exactly what is needed. Thanks.

#6 Updated by Benoît PECCATTE 5 months ago

  • Assignee set to Nicolas CHARLES

#7 Updated by Benoît PECCATTE 4 months ago

  • Effort required changed from Small to Very Small
  • Priority changed from 55 to 68

#8 Updated by Vincent MEMBRÉ 4 months ago

  • Target version changed from 3.1.22 to 3.1.23

#9 Updated by Vincent MEMBRÉ 3 months ago

  • Target version changed from 3.1.23 to 3.1.24
  • Priority changed from 68 to 67

#10 Updated by Nicolas CHARLES 3 months ago

  • Related to User story #11346: Create a new generic method to set key/value with option to define if it is strict or not added

#11 Updated by Nicolas CHARLES 3 months ago

  • Status changed from New to In progress

#12 Updated by Nicolas CHARLES 3 months ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Nicolas CHARLES to Alexis MOUSSET
  • Pull Request set to https://github.com/Normation/rudder-techniques/pull/1191

#13 Updated by Nicolas CHARLES 3 months ago

  • Status changed from Pending technical review to Pending release

#14 Updated by Vincent MEMBRÉ about 1 month ago

  • Status changed from Pending release to Released
  • Priority changed from 67 to 65

This bug has been fixed in Rudder 3.1.24, 4.1.8 and 4.2.1 which were released today.

Also available in: Atom PDF