Re: [PATCH 2/2] libselinux: support multiple contexts for the file backend

On Wed, Jul 22, 2026 at 2:58 AM Stephen Smalley
<[email protected]> wrote:
>
> On Mon, Jul 20, 2026 at 10:11 PM Thiébaud Weksteen <[email protected]> wrote:
> >
> > Update the file labeling backend to support specifying multiple
> > SELABEL_OPT_PATH options in selabel_open().
> >
> > All provided paths are stored in rec->spec_files and processed during
> > initialization. Derived files, such as substitutions (.subs, .subs_dist)
> > and auxiliary contexts (.homedirs, .local), continue to be based on the
> > first path (or default selinux_file_context_path()) when enabled.
> >
> > Duplicate checking logic is refactored into a helper function
> > report_dups(). A duplicate with the same specification result is not
> > fatal anymore, but a warning is still logged.
> >
> > Additionally, duplicate validation is moved after all files (including
> > .homedirs and .local) are loaded and sorted. For single file context setups,
> > the only difference in behavior is that duplicate validation now extends to
> > fc.homedirs and fc.local.
>
> Not sure if this change in behavior is desired - it seemingly
> precludes .local from intentionally overriding an entry's context.
> Defer to distro maintainers.
>
> >
> > A similar multiple files setup has been used in Android for 9+ years.
> >
> > Signed-off-by: Thiébaud Weksteen <[email protected]>

Thanks for the quick review Stephen. Overall I agree with all your
feedback and will send an updated patch.

> > +       /* If no paths were provided, we will use the default path or fail, depending on the target. */
> > +       if (!path_provided) {
> > +#if !defined(BUILD_HOST) && !defined(ANDROID)
> > +               num_paths = 1;
> > +#else
> > +               selinux_log(SELINUX_ERROR,
> > +                           "No path given to file labeling backend\n");
> > +               goto finish;
> > +#endif
> Do we really need/want differing behavior here for different build configs?
> Effectively it means a different user-visible API?

If I understand correctly, this difference already exists. If ANDROID
is defined and if no SELABEL_OPT_PATH were supplied, path is NULL and
selinux_file_context_path() is never called; which means that `if
(!path)` below will be executed and return EINVAL (I should have kept
that return value in my change).

More generally, we had to implement a layer on top of selabel_open for
Android-specific file_contexts locations [1]. I am wondering if we
could improve the design and abstract any standard-distro details
(e.g., homedirs). Fundamentally, selabel_open for file_contexts would
either: use the file paths provided as argument; or otherwise use the
"platform default". Right now, "platform default" means
(selinux_file_context_path + homedirs + local + subs). What if we
define a callback that returns a set of files to use and optional
subs? We could keep any Android-specific changes in our own "platform
default" implementation (which would be behind a build configuration
option).

[1] https://cs.android.com/android/platform/superproject/+/android-latest-release:external/selinux/libselinux/src/android/android_seapp.c;l=101

> >  /*
> > - * Warn about duplicate specifications.
> > + * Report a duplicate in the log.
> > + *
> > + * If the duplicate is considered fatal (i.e., if the specifications of both
> > + * entries do not match), return -1 and set errno to EINVAL.
> > + */
> > +static int report_dups(struct selabel_handle *rec, uint8_t inputno1,
> > +                      uint8_t inputno2, const char *ctx_raw1,
> > +                      const char *ctx_raw2, const char *match,
> > +                      const char *file_kind)
> > +{
> > +       if (inputno1 >= rec->spec_files_len)
> > +               inputno1 = 0;
> > +       if (inputno2 >= rec->spec_files_len)
> > +               inputno2 = 0;
>
> Not sure if this change in behavior is desired - it seemingly
> precludes .local from intentionally overriding an entry's context.
> Defer to distro maintainers.
> Since you are intentionally passing in num_paths + 1 and num_paths + 2
> for the homedirs and local files, this will incorrectly attribute any
> duplicates to the wrong file. Not sure we want cross-file duplicate
> checking anyway.

Thanks, I wasn't sure about this as I don't know how these files are
used in other distributions. I agree, keeping the existing behaviour
is better.