config_setting visibility not enforced

[ulrfa]

Description of the problem / bug:

It should not be allowed to access a private config_setting from select in other package. But bazel fails to enforce the visibility.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

pkgA/BUILD:

load(
    "@bazel_skylib//rules:common_settings.bzl",
    "bool_flag",
)

bool_flag(
    name = "myFlag",
    build_setting_default = False,
    # This visibility is working, however the config_setting is in same package.
    visibility = ["//visibility:private"]
)

config_setting(
    name = "mySetting",
    flag_values = {"myFlag": "True"},
    # This can be accessed from pkgB, despite private visibility
    visibility = ["//visibility:private"]
)

pkgB/BUILD:

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.out"],
    # Can access mySetting from another package, despite private visibility. 
    cmd = select({
        "//pkgA:mySetting": "echo running with mySetting > $@",
        "//conditions:default": "echo running default > $@"}),
)

I expect both of the following commands to fail, due to pkgB accessing private config_setting in pkgA, but no error is detected:

bbi_bazel build //pkgB:foo --//pkgA:myFlag=True
bbi_bazel build //pkgB:foo --//pkgA:myFlag=False

What operating system are you running Bazel on?

Linux

What's the output of bazel info release?

3.7.0

Have you found anything relevant by searching the web?

I searched, but have not found anything.

[gregestren]

Thanks for this report. This is easily reproducible.

I believe the solution is to:

1. Include config_setting in

   bazel/src/main/java/com/google/devtools/build/lib/analysis/RuleContext.java

   Line 2073 in 5753b32

   validateDirectPrerequisite(attribute, configuredTarget);

2. so its visibility is checked at

   bazel/src/main/java/com/google/devtools/build/lib/analysis/CommonPrerequisiteValidator.java

   Line 69 in 8346ea4

   private void validateDirectPrerequisiteVisibility(

3. This requires accessing config_setting from RuleContext.Builder as a ConfiguredTarget
4. RuleContext.Builder stores its config_settings as ConfigMatchingProviders:

   bazel/src/main/java/com/google/devtools/build/lib/analysis/RuleContext.java

   Line 244 in 5753b32

   ImmutableMap<Label, ConfigMatchingProvider> configConditions,

5. These are populated from

   bazel/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetFunction.java

   Line 722 in 63e0392

   static ImmutableMap<Label, ConfigMatchingProvider> getConfigConditions(

   which retrieves the ConfiguredTargets but only preserves the providers.
6. So we'd need to modify that code to keep access to the entire ConfiguredTarget.

Actually, another approach could be to do visibility checking directly in step 5. It's not ideal, since it's carving out yet another special code path for config_setting vs. other dependencies. But it'd be a lot less intrusive of a change.

[lisaonduty]

Hi,

I work with @ulrfa so I have also seen this lack of visibility setting. But then last week a user got a strange error where the visibility did matter and we thought that it was very strange. It showed out that the user used config_setting_group in Skylib and then it didn't work with faulty visibility settings.

Just to show as information:

pkgA/BUILD

load(
    "@bazel_skylib//rules:common_settings.bzl",
    "bool_flag",
)

bool_flag(
    name = "myFlagA",
    build_setting_default = False,
    # This visibility is working, however the config_setting is in same package.
    visibility = ["//visibility:private"]
)

bool_flag(
    name = "myFlagB",
    build_setting_default = False,
    # This visibility is working, however the config_setting is in same package.
    visibility = ["//visibility:private"]
)

config_setting(
    name = "mySettingA",
    flag_values = {"myFlagA": "True"},
    # This can be accessed from pkgB, despite private visibility
    visibility = ["//visibility:private"]
)

config_setting(
    name = "mySettingB",
    flag_values = {"myFlagB": "True"},
    # This can be accessed from pkgB, despite private visibility
    visibility = ["//visibility:private"]
)

pkgB/BUILD

load("@bazel_skylib//lib:selects.bzl", "selects")

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.out"],
    # Can access mySetting from another package, despite private visibility.
    cmd = select({
        "//pkgB:mySettingAandB": "echo running with mySetting > $@",
        "//conditions:default": "echo running default > $@"}),
)

selects.config_setting_group(
    name = "mySettingAandB",
    match_all = [
        "//pkgA:mySettingA",
        "//pkgA:mySettingB",
    ],
)

Then it will not work to build due to the private visibility setting:

bazel build //pkgB:foo --//pkgA:myFlagA=False --//pkgA:myFlagB=False

ERROR: /pkgB/BUILD:13:29: in alias rule //pkgB:mySettingAandB: target '//pkgA:mySettingA' is not visible from target '//pkgB:mySettingAandB'. Check the visibility declaration of the former target if you think the dependency is legitimate

It probably don't impact the needed update in Bazel that you @gregestren suggest but I just thought that it was an interesting finding to share. Me and @ulrfa was really confused when we got the fault even though we previous had seen that visibility for config_setting didn't work.

[gregestren]

Hi @lisaonduty.

I agree that's subtle. The difference is that for select({<someKey>: <someValue>}), anything in <someKey> doesn't get visibility-checked, while anything in <someValue> gets visibility-checked as a normal dependency.

config_setting_group applies some macro magic that we can unwind with a query:

$  bazel query --output=build //pkgB:all
alias(
  name = "mySettingAandB",
  generator_name = "mySettingAandB",
  generator_function = "_config_setting_group",
  generator_location = "pkgB/BUILD:14:29",
  actual = select({"//pkgA:mySettingA": "//pkgA:mySettingB", "//conditions:default": "//pkgA:mySettingA"}),
)

You can see mySettingAandB gets unrolled to an alias where the select's <someValue> includes the config_setting.

[lisaonduty]

Thanks @gregestren for the explanation and also the tip about query. I didn't thought of using the query in this use case.

[gregestren]

Put up a proof of concept PR at #12877.

[gregestren]

FYI: I rolled back my PR because it breaks some projects that already set visibility on config_setting with bad values.

I'm rolling it forward again behind a flag. Stay tuned...

[gregestren]

Filed bugs for --incompatible_* flags: #12932. PR using them incoming.