Skip to content

Use unified configfile parser for policy.json#711

Open
jankaluza wants to merge 11 commits intocontainers:mainfrom
jankaluza:policy.json
Open

Use unified configfile parser for policy.json#711
jankaluza wants to merge 11 commits intocontainers:mainfrom
jankaluza:policy.json

Conversation

@jankaluza
Copy link
Copy Markdown
Member

@jankaluza jankaluza commented Mar 23, 2026

This PR switches policy.json loading to the unified storage/pkg/configfile parser instead of maintaining separate lookup logic in image/signature.

The SignaturePolicyPath support is preserved, so explicit callers continue to work as before. The policy loader also now uses CONTAINERS_POLICY_JSON for environment-based override. The CONTAINERS_POLICY_JSON_OVERRIDE remains ignored for policy.json because drop-in loading is disabled for that this configuration file.

It also extends the configfile API to return the paths it searched. This is showed to users when there is no policy.json found.

Fixes: #207
Fixes: #202

@github-actions github-actions bot added common Related to "common" package image Related to "image" package labels Mar 23, 2026
@jankaluza
Copy link
Copy Markdown
Member Author

@Luap99 , Hi, could you please check if this PR makes a sense? I also added two questions for parts of code I'm not sure about...

Copy link
Copy Markdown
Contributor

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

Just an extremely brief skim.

return filepath.Join(sys.RootForImplicitAbsolutePaths, systemPolicyPath), nil
var policy *Policy
found := false
for item, err := range configfile.Read(&policyFiles) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This loop does not work; there is no merging. Is the intent to discard the policy values until the last one?!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

right, since we did not wanted to define merging rules the design doc says no drop in support and as such the main file will only ever be one per current parsing rules

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Reading more precisely, this loop should only iterate at most once; do we want to assert that?

@github-actions github-actions bot added the storage Related to "storage" package label Mar 24, 2026
@jankaluza jankaluza changed the title WIP: Use unified configfile parser for policy.json Use unified configfile parser for policy.json Mar 24, 2026
Copy link
Copy Markdown
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

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

it would be good to if you can squash the re-add SignaturePolicyPath commits, i.e when reviewing this it makes no sense to look at something getting remove to be added again. It also break git bisect most likely when vendoring from another repo.

}

if conf.EnvironmentName != "" {
if conf.EnvironmentName != "" && !conf.DoNotLoadDropInFiles {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

please add a new test case here for that behavior

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

And document that behavior! It’s rather unexpected based on plain reading of the current option (although there is some logic to it).

Probably not, but maybe we’d want s/DoNotLoadDropInFiles/DropInFilesUnsupported/ ?!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I am in favour of naming it DropInFilesUnsupported, though then I guess we would want to rename DoNotLoadMainFiles as well to MainFilesUnsupported? I suppose we could rename that outside of the scope of this PR if wanted.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I kind of think of them as different dimensions: “do not load a file at $this path” is more of a directive vs. “the consumer cannot process multiple drop-ins regardless of names” is more of a capability declaration, but that’s a very weak reasoning.

I’m also quite fine with leaving the name as is.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I would remove that in another PR if possible to not add more unrelated changes to this one if that's fine for you. I added the documentation part, that's good point :-).

Copy link
Copy Markdown
Contributor

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

Thanks!

}

if conf.EnvironmentName != "" {
if conf.EnvironmentName != "" && !conf.DoNotLoadDropInFiles {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

And document that behavior! It’s rather unexpected based on plain reading of the current option (although there is some logic to it).

Probably not, but maybe we’d want s/DoNotLoadDropInFiles/DropInFilesUnsupported/ ?!

// Path overridden
{&types.SystemContext{SignaturePolicyPath: nondefaultPath}, false, true, nondefaultPath, ""},
// Root overridden
for _, test := range []tc{
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I’m rather unhappy about no longer being able to truly test SystemContext == nil and SystemContext{}, but I also don’t see any good way to do that. This will just have to trust configfile.Read for that.

At least, please test (SystemContext == nil, SystemContext{})+(XDG_CONFIG_HOME,CONTAINERS_POLICY_CONF), enough to confirm that we got what we wanted (while we don’t control what exists in /etc and /usr)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

AFAICS there are no tests for SystemContext == nil and SystemContext{}.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Still no test for SystemContext == nil?

@jankaluza jankaluza force-pushed the policy.json branch 3 times, most recently from 89fd676 to d9da724 Compare March 30, 2026 14:07
Copy link
Copy Markdown
Contributor

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

I didn’t carefully read the added tests or think about coverage, I’m hoping for a simpler version first.

There are also a bunch of earlier outstanding review comments.

// Path overridden
{&types.SystemContext{SignaturePolicyPath: nondefaultPath}, false, true, nondefaultPath, ""},
// Root overridden
for _, test := range []tc{
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

AFAICS there are no tests for SystemContext == nil and SystemContext{}.

@packit-as-a-service
Copy link
Copy Markdown

Packit jobs failed. @containers/packit-build please check.

Copy link
Copy Markdown
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

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

(commit 3 should be squashed into commit 1 and that one needs WIP stripped)

Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
jankaluza added 10 commits April 2, 2026 13:06
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
When no policy.json is found, `DefaultPolicy()`` previously returned a
generic error without indicating where the system looked for the file.

This commit introduces `configfile.ReadWithPaths()` to track all
attempted config file locations during iteration. It uses this
in DefaultPolicy() to include the searched paths in the error message
when no policy file is found.

Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
This commit does the following:

- The `setup()` function now returns the SystemContext.
- The hardcoded check for "no policy file found" has moved to
  the test itself.
- Fixture is used for SignaturePolicyPath.

Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
This commit introduces `File.ErrorIfNotFound`. If it is true, the Read
returns an error which contains all the paths it tried when searching
for a config file.

The ReadWithPaths is replaced by this new logic.

Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
@Luap99
Copy link
Copy Markdown
Member

Luap99 commented Apr 8, 2026

@mtrmac are you fine with the new approach suggested by me?

@jankaluza Generally speaking I would like to see a "clean" history, i.e. not add ReadWithPaths just to remove it again as this makes reviewing harder but lets with for @mtrmac feedback first

@jankaluza
Copy link
Copy Markdown
Member Author

@Luap99 , yeah, I will squash the commits before merge.

Copy link
Copy Markdown
Contributor

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

Sure, the ErrorIfNotFound approach is (given the signature-side test) fine. We can rework storage/configfile as needed. ACK overall.

Some outstanding nits:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

common Related to "common" package image Related to "image" package storage Related to "storage" package

Projects

None yet

3 participants