Project

General

Profile

Actions

Bug #11087

closed

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

Added by Hamlyn Mootoo over 7 years ago. Updated about 7 years ago.

Status:
Released
Priority:
N/A
Category:
Techniques
Target version:
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Very Small
Priority:
65
Name check:
Fix check:
Regression:

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 1 (0 open1 closed)

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

Related issues 1 (0 open1 closed)

Related to Rudder - User story #11346: Create a new generic method to set key/value with option to define if it is strict or notReleasedAlexis MoussetActions
Actions #1

Updated by Alexis Mousset over 7 years 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
Actions #2

Updated by Hamlyn Mootoo over 7 years 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.

Actions #3

Updated by Hamlyn Mootoo over 7 years 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
Actions #4

Updated by Nicolas CHARLES over 7 years 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

Actions #5

Updated by Hamlyn Mootoo over 7 years ago

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

Actions #6

Updated by Benoît PECCATTE over 7 years ago

  • Assignee set to Nicolas CHARLES
Actions #7

Updated by Benoît PECCATTE over 7 years ago

  • Effort required changed from Small to Very Small
  • Priority changed from 55 to 68
Actions #8

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.22 to 3.1.23
Actions #9

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.23 to 3.1.24
  • Priority changed from 68 to 67
Actions #10

Updated by Nicolas CHARLES over 7 years 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
Actions #11

Updated by Nicolas CHARLES over 7 years ago

  • Status changed from New to In progress
Actions #12

Updated by Nicolas CHARLES over 7 years 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
Actions #13

Updated by Nicolas CHARLES over 7 years ago

  • Status changed from Pending technical review to Pending release
Actions #14

Updated by Vincent MEMBRÉ about 7 years 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.

Actions

Also available in: Atom PDF