Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The sss daemon which uses the same configuration file can be started without any parse issues; that is - this is more of a inconsistency problem than a bug.
Also, note that the default sssd.conf file contains configuration directives preceded with whitespace characters. so this fails by default.
Version-Release number of selected component (if applicable):
sssd-1.8.0-32.el6.x86_64
sssd-client-1.8.0-32.el6.x86_64
sssd-tools-1.8.0-32.el6.x86_64
How reproducible:
always
Steps to Reproduce:
1. run sss_obfuscate --domain <domain> <<< <password>
or
1. edit /etc/sssd/sssd.conf
2. add a preceding whitespace to any not-commented configuration line
3. run sss_obfuscate --domain <domain> <<< <password>
Actual results:
Traceback (most recent call last):
File "/usr/sbin/sss_obfuscate", line 117, in <module>
ret = main()
File "/usr/sbin/sss_obfuscate", line 84, in main
sssdconfig.import_config(options.filename)
File "/usr/lib/python2.6/site-packages/SSSDConfig.py", line 1213, in import_config
raise ParsingError
SSSDConfig.ParsingError
Expected results:
No output, return code 0 and obfuscated password inserted into the configuration file.
Additional info:
The problem seems to be the regex pattern on line 496 in ipachangeconf.py:
OPTCRE = re.compile(
r'(?P<option>[^:=\s][^:=]*)' # very permissive!
r'\s*=\s*' # any number of space/tab,
# followed by separator
# followed by any # space/tab
r'(?P<value>.*)$' # everything up to eol
)
Allowing any number of preceding whitespaces seems to fix the issue:
OPTCRE = re.compile(
r'\s*(?P<option>[^:=\s][^:=]*)' # very permissive!
r'\s*=\s*' # any number of space/tab,
# followed by separator
# followed by any # space/tab
r'(?P<value>.*)$' # everything up to eol
)
Comment 2Stephen Gallagher
2012-06-25 13:53:10 UTC
The source of the confusion is that the example config file includes directives that are commented out with a space between the comment delimiter and the directive. Simply removing the comment delimiter is not sufficient to enable the option properly.
We should change the default config file so that this is more clear.
For the record, it is intentional that leading whitespace is not ignored, as we intend in the future to use leading whitespace as a delimiter for a multi-line value.
Comment 3Stephen Gallagher
2012-06-25 13:55:01 UTC
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux.
Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as DEFERRED. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.
Note that you can still track this request or even contribute patches in the referred upstream Trac ticket.
Comment 7sarausa
2024-03-01 02:18:33 UTC
Comment hidden (spam)
This comment was flagged a spam, view the edit history to see the original text if required.
Comment 8splitloop
2024-03-27 00:58:15 UTC
Comment hidden (spam)
This comment was flagged a spam, view the edit history to see the original text if required.
Description of problem: The sss daemon which uses the same configuration file can be started without any parse issues; that is - this is more of a inconsistency problem than a bug. Also, note that the default sssd.conf file contains configuration directives preceded with whitespace characters. so this fails by default. Version-Release number of selected component (if applicable): sssd-1.8.0-32.el6.x86_64 sssd-client-1.8.0-32.el6.x86_64 sssd-tools-1.8.0-32.el6.x86_64 How reproducible: always Steps to Reproduce: 1. run sss_obfuscate --domain <domain> <<< <password> or 1. edit /etc/sssd/sssd.conf 2. add a preceding whitespace to any not-commented configuration line 3. run sss_obfuscate --domain <domain> <<< <password> Actual results: Traceback (most recent call last): File "/usr/sbin/sss_obfuscate", line 117, in <module> ret = main() File "/usr/sbin/sss_obfuscate", line 84, in main sssdconfig.import_config(options.filename) File "/usr/lib/python2.6/site-packages/SSSDConfig.py", line 1213, in import_config raise ParsingError SSSDConfig.ParsingError Expected results: No output, return code 0 and obfuscated password inserted into the configuration file. Additional info: The problem seems to be the regex pattern on line 496 in ipachangeconf.py: OPTCRE = re.compile( r'(?P<option>[^:=\s][^:=]*)' # very permissive! r'\s*=\s*' # any number of space/tab, # followed by separator # followed by any # space/tab r'(?P<value>.*)$' # everything up to eol ) Allowing any number of preceding whitespaces seems to fix the issue: OPTCRE = re.compile( r'\s*(?P<option>[^:=\s][^:=]*)' # very permissive! r'\s*=\s*' # any number of space/tab, # followed by separator # followed by any # space/tab r'(?P<value>.*)$' # everything up to eol )