Skip to content

Remove hard-coded default for RHS #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nalind
Copy link
Contributor

@nalind nalind commented May 3, 2016

Don't fall back to using a default LHS or RHS when the configuration file can't be read. Original report from https://bugzilla.redhat.com/show_bug.cgi?id=1332493

@kaduk
Copy link

kaduk commented May 3, 2016

LGTM

@achernya
Copy link
Owner

achernya commented May 3, 2016

Hm, this seems to break the tests

Can't initialize hesiod library.
FAIL: hestest.conf

@nalind Can you take a look at the failure?

@nalind
Copy link
Contributor Author

nalind commented May 3, 2016

Would it make more sense to continue setting a default LHS, erroring out if we can't read an RHS and also don't find one in the environment? Setting HES_DOMAIN during the tests should be enough for them.

@nalind
Copy link
Contributor Author

nalind commented May 3, 2016

Okay, giving that a try.

@nalind nalind changed the title Remove hard-coded defaults for LHS and RHS Remove hard-coded default for RHS May 3, 2016
@nalind nalind force-pushed the no_def_lhsrhs branch 3 times, most recently from 362b76d to 2e8be6a Compare May 3, 2016 18:51
@nalind
Copy link
Contributor Author

nalind commented May 3, 2016

Okay, switching back to setting a default LHS if we fail to read the configuration file, and erroring out later if there isn't an acceptable RHS value set in the environment, and making sure that HES_DOMAIN is set to "athena.mit.edu" when we run hestest, seems to work.

/* Make sure that the rhs is set. */
if (!ctx->rhs)
{
errno = ENOEXEC;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why ENOEXEC here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's copied from read_config_file(), though I have no idea why read_config_file() uses that particular error code. Would ENOENT make more sense?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EINVAL or ENOENT make more sense

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'm leaning toward EINVAL because at that point we may well have managed to read a configuration file, so ENOENT could be confusing.

Don't fall back to using a default LHS or RHS when the configuration
file can't be read.  Instead, return an error.
Original report from https://bugzilla.redhat.com/show_bug.cgi?id=1332493
@nalind
Copy link
Contributor Author

nalind commented May 4, 2016

Hmm, the more I think about this, the more I'm leaning toward going back to just returning an error when we fail to open the file, and setting HESIOD_CONFIG to point to the in-tree hesiod.conf.sample file when we run hestest. That seems to be enough for it here. Opinions?

@achernya
Copy link
Owner

achernya commented May 4, 2016

I would be okay with pointing hestest at a config file. That seems most correct if you're improving the unconfigured state.

@nalind
Copy link
Contributor Author

nalind commented May 4, 2016

Okay, I'll switch this over to doing that.

@kaduk
Copy link

kaduk commented May 4, 2016

Yes, having the tests point to an explicit config file and not relying on default behavior seems like a fine plan.

@nalind
Copy link
Contributor Author

nalind commented May 10, 2016

Okay, the changes are ready.

@carnil
Copy link

carnil commented Jan 21, 2017

This has been assigned CVE-2016-10152

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants