conf.c: Fix stopping scheduler on unknown directive

[zdohnal]

Change the return value to do not trigger stopping the scheduler in case of unknown directive, because stopping the scheduler on config errors should only happen in case of syntax errors.

[michaelrsweet]

@zdohnal I want to think about this one for a minute...

[zdohnal]

@michaelrsweet no problem - I have removed the part with checking for value there. IMO we get into the scope because the directive is unknown, so it looks unnecessary to report that unknown directive does not have a value - it effectively hid the fact the directive is unknown as well.

[jsmeix]

@zdohnal
you requested a review from me
but we at SUSE are not affected
by the recent issues in this area.
So feel free to merge what you think is best.

Personally I think it is good when by default
cupsd does not start when its config has issues
because cupsd runs as root so a proper config
of a 'root' process is a major security concern.

For example assume there is a CUPS update
which does no longer support some config setting.
Then it could result a security issue when a user
still uses this config setting from his old config
and new cupsd runs and ignores what is now invaild.
Perhaps security in the user's specific environment
somehow depends on this specific config setting?

Usually users won't look at log files
as long as it "just works", cf. "just work" in
https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings

[mdeslaur]

I think doing this makes sense on the 2.4.x branch, to prevent the behavioural change that is causing issues for some users. While the 5661ec7 commit does fix some of the configuration elements caused by CUPS itself, per PR 1445, it has been reported that some users also have ancient configuration directives such as "BrowseAddress" and "BrowseOrder" which up until now didn't prevent the CUPS daemon from starting.

[michaelrsweet]

I think I want to add a new "unknown" value (fail on unknown configuration directives) for FatalErrors in CUPS 2.5, and then for CUPS 2.4.x and earlier we just (for now) use this "workaround" for the old/misplaced directives.

So approving this as-is to apply to master and 2.4.x, and I'll file a new issue against 2.5 for the "unknown" value for FatalErrors.