Bug 1456968

Summary: MAN: document that attribute 'provider' is not allowed in section 'secrets'
Product: Red Hat Enterprise Linux 7 Reporter: Amith <apeetham>
Component: sssdAssignee: SSSD Maintainers <sssd-maint>
Status: CLOSED ERRATA QA Contact: Amith <apeetham>
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.4CC: amitkuma, apeetham, fidencio, grajaiya, jhrozek, lslebodn, mkosek, mzidek, pbrezina, sgoveas, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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 17:11:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Amith 2017-05-30 19:25:52 UTC
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 18:43:44 UTC
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 04:03:55 UTC
(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 07:56:32 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3417

Comment 6 Lukas Slebodnik 2017-09-06 06:07:30 UTC
master:
* e8bad995fb1219df2a4fef8f55c80284c6ab36d3

Comment 8 Amith 2017-11-30 09:53:32 UTC
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 17:11:33 UTC
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