Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1456968 - MAN: document that attribute 'provider' is not allowed in section 'secrets'
MAN: document that attribute 'provider' is not allowed in section 'secrets'
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity low
: rc
: ---
Assigned To: SSSD Maintainers
Amith
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-05-30 15:25 EDT by Amith
Modified: 2018-04-19 03:20 EDT (History)
11 users (show)

See Also:
Fixed In Version: sssd-1.16.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 13:11:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0929 None None None 2018-04-10 13:12 EDT

  None (edit)
Description Amith 2017-05-30 15:25:52 EDT
Description of problem:
SSSD-secrets man page suggests "provider" option which can be set as "local" or "proxy". SSSD.log shows error when secrets section is configured as given below:

[secrets]
provider = local

The sssd.log error states: 
"[rule/allowed_sec_options]: Attribute 'provider' is not allowed in section 'secrets'. Check for typos."

When provider option is removed or commented, the error disappears. This error is misleading.

Version-Release number of selected component (if applicable):
sssd-1.15.2-37.el7.x86_64

How reproducible:
Always
Comment 2 Jakub Hrozek 2017-05-31 14:43:44 EDT
That's currently expected. The provider can only be specified for the per-user/per-uid section. The global provider is always local.This is tracked with https://pagure.io/SSSD/sssd/issue/3139 but I agree the manpage is outright confusing. Would it be OK to say for now that the provider must be per-user in the manpage?
Comment 3 Amith 2017-06-01 00:03:55 EDT
(In reply to Jakub Hrozek from comment #2)
> That's currently expected. The provider can only be specified for the
> per-user/per-uid section. The global provider is always local.This is
> tracked with https://pagure.io/SSSD/sssd/issue/3139 but I agree the manpage
> is outright confusing. Would it be OK to say for now that the provider must
> be per-user in the manpage?

Yes, that will do. Thanks Jakub.
Comment 4 Jakub Hrozek 2017-06-01 03:56:32 EDT
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3417
Comment 6 Lukas Slebodnik 2017-09-06 02:07:30 EDT
master:
* e8bad995fb1219df2a4fef8f55c80284c6ab36d3
Comment 8 Amith 2017-11-30 04:53:32 EST
Verified the bug on SSSD Version : sssd-1.16.0-7.el7.x86_64

The following changes are updated in the man page for sssd-secrets :

CONFIGURATION OPTIONS
       The generic SSSD responder options such as “debug_level” or “fd_limit” are accepted by the secrets responder. Please refer to the sssd.conf(5) manual page for a complete list. In addition, there are some secrets-specific options as well.

       The secrets responder is configured with a global “[secrets]” section and an optional per-user “[secrets/users/$uid]” section in sssd.conf. Please note that some options, notably as the provider type, can only be specified in the per-user subsections.

       provider (string)
           This option specifies where should the secrets be stored. The secrets responder can configure a per-user subsections (e.g.  “[secrets/users/123]” - see bottom of this manual page for a full example using Custodia for a particular user) that define which provider store the secrets for this particular user. The per-user subsections should contain all options for that user's provider. Please note that currently the global provider is always local, the proxy provider can only be specified in a per-user section.
Comment 11 errata-xmlrpc 2018-04-10 13:11:33 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0929

Note You need to log in before you can comment on or make changes to this bug.