Bug 1459786

(In reply to Madhuri from comment #0)
> Description of problem:
> It is not clear what special characters are allowed in domain name part in
> default configuration file and snippet files in SSSD.
> 
> 
> Version-Release number of selected component (if applicable):
> sssd-1.15.2-43.el7.x86_64
> 
> How reproducible:
> Always..
> 
> Steps to Reproduce:
> 1. Install sssd and sssd-tools package and configure SSSD client.
> 2. Create sssd configuration file with typo(add special character) in domain
> name of sssd configuration file.
> 
> # cat /etc/sssd/sssd.conf | grep domain
> domains = L&DAP
> [domain/L&DAP]

Why do you think that "&" should not be allowed in domain name?

man sssd.conf says:
"A domain name should only consist of alphanumeric ASCII characters, dashes, dots and underscores."

Is that not sufficient?

(In reply to Jakub Hrozek from comment #3)
> man sssd.conf says:
> "A domain name should only consist of alphanumeric ASCII characters, dashes,
> dots and underscores."
> 
So title of this BZ is wrong. Because it is clear that what special characters are allowed in domain part in SSSD.

> Is that not sufficient?

The problem is that we do not check it anywhere in the code. And checking it just in opional config-check is not enough.

BTW "domains = white`hat.com" would work if we properly escape address in dbus addresses.

(Thu Jun  8 12:15:07 2017) [sssd[be[white`hat.com]]] [sbus_new_server] (0x0020): dbus_server_listen failed! (name=org.freedesktop.DBus.Error.BadAddress, message=In D-Bus address, character '`' should have been escaped
)
(Thu Jun  8 12:15:07 2017) [sssd[be[white`hat.com]]] [dp_init_dbus_server] (0x0010): Could not set up sbus server.
(Thu Jun  8 12:15:07 2017) [sssd[be[white`hat.com]]] [dp_init] (0x0010): Unable to setup service bus [5]: Input/output error
(Thu Jun  8 12:15:07 2017) [sssd[be[white`hat.com]]] [dp_terminate_active_requests] (0x0400): Terminating active data provider requests
(Thu Jun  8 12:15:07 2017) [sssd[be[white`hat.com]]] [be_process_init] (0x0010): Unable to setup data provider [5]: Input/output error
(Thu Jun  8 12:15:07 2017) [sssd[be[white`hat.com]]] [main] (0x0010): Could not initialize backend [5]


And it is a little bit late to realize error when starting back-end.

So we need to update the regex in schema to reflect the documentation.

I have a question that is kind of related to this.

Should we prevent SSSD from starting when the validators find an issue on startup? It will not be necessary to write additional checks in the code for issues like this in order to fail with sane error message. We could rely on the validators to catch these issues.

We could have command line argument to disable/enable this behavior (so that we have a workaround for cases where the schema has bugs - and I am sure there will be some).

Opinions?
Should we create some downstream BZs, to track the above?

Michal

(In reply to Michal Zidek from comment #5)
> So we need to update the regex in schema to reflect the documentation.
> 
> I have a question that is kind of related to this.
> 
> Should we prevent SSSD from starting when the validators find an issue on
> startup? It will not be necessary to write additional checks in the code for
> issues like this in order to fail with sane error message. We could rely on
> the validators to catch these issues.
> 

I'm not sure if this is possible, there might be scenarios where there are already config files out in the wild with typos. And as you say, we might have bugs in the schema. There is plenty of users who use the same configuration across RHEL-6/7 and they don't care about warnings.


> We could have command line argument to disable/enable this behavior (so that
> we have a workaround for cases where the schema has bugs - and I am sure
> there will be some).
> 

If we have such a switch, would we ever enable it? 

> Opinions?
> Should we create some downstream BZs, to track the above?
> 
> Michal

(In reply to Jakub Hrozek from comment #6)
> (In reply to Michal Zidek from comment #5)
> > So we need to update the regex in schema to reflect the documentation.
> > 
> > I have a question that is kind of related to this.
> > 
> > Should we prevent SSSD from starting when the validators find an issue on
> > startup? It will not be necessary to write additional checks in the code for
> > issues like this in order to fail with sane error message. We could rely on
> > the validators to catch these issues.
> > 
> 
> I'm not sure if this is possible, there might be scenarios where there are
> already config files out in the wild with typos. And as you say, we might
> have bugs in the schema. There is plenty of users who use the same
> configuration across RHEL-6/7 and they don't care about warnings.

I think you are right. It could be to invasive.

> 
> 
> > We could have command line argument to disable/enable this behavior (so that
> > we have a workaround for cases where the schema has bugs - and I am sure
> > there will be some).
> > 
> 
> If we have such a switch, would we ever enable it?

I would at least enable it in the CI to catch errors in schema sooner.

> 
> > Opinions?
> > Should we create some downstream BZs, to track the above?
> > 
> > Michal

(In reply to Michal Zidek from comment #7)
> > If we have such a switch, would we ever enable it?
> 
> I would at least enable it in the CI to catch errors in schema sooner.

That would be nice.

I've captured the discussion into the downstream ticket #3334 and I'm going to close this bugzilla as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1432325

Madhuri, thank you very much for filing this bug.

*** This bug has been marked as a duplicate of bug 1432325 ***