> -----Original Message----- > From: Stephen Smalley [mailto:stephen.smal...@gmail.com] > Sent: Thursday, December 31, 2015 11:01 AM > To: Roberts, William C <william.c.robe...@intel.com> > Cc: William Roberts <bill.c.robe...@gmail.com>; seandroid-list@tycho.nsa.gov > Subject: Re: fc ordering > > On Thu, Dec 31, 2015 at 12:53 PM, Roberts, William C > <william.c.robe...@intel.com> wrote: > > > > <snip> > > > >>> libselinux only "sorts" in the sense of giving precedence to exact > >>> (no regex characters) entries. The sorting described in the page > >>> you referenced is done by libsemanage or by the fc_sort helper > >>> program used in the refpolicy build and is not part of Android at > >>> all. That sorting was introduced to help with ambiguities that > >>> occur when file_contexts was split into per-module .fc files. > >>That's essentially the problem we have in our build. Each module is added > during the build via sepolicy dirs variable. Perhaps then we should look at > adding > fc_sort during build? > >>Android however > >>> only has a single monolithic file_contexts file, and even with the > >>> device-specific file_contexts, the assumption is that those entries > >>> should always take precedence over the generic ones (as long as they > >>> are not identical and conflict). So order does matter. Last > >>> matching entry wins. > > > > Does anyone object to adding something like sort_fc to the build to > > alleviate > this ordering issue? > > > > Now that we switch to checking the fc files with checkfc, I'm not aware of > > any > other CTS issues. > > I guess the question is whether we want to sort the entire file_contexts this > way > (which could potentially cause an entry from the AOSP general file_contexts to > override a device-specific entry) or individually sort the general and device- > specific file_contexts and then concatenate the two. The sorting is > heuristic- > based, as there is no precise ordering that can be defined among regular > expressions.
IIUC, If we sort the entire fc entries (general + device), then the heuristics per that fedora page would allow "more specific" device entries to override general entries. However, just sorting the device policy would also be Ok with me, since it would solve my issue In the modular style policy build. > > > BTW in the CTS test, why didn't we just modify checkfc to return status > > codes > for equal, subset, superset? We have all this "complicated" > > stdio checking for exact matching. > > I followed the example of other tests which were output-based, and also exit > status can be misleading, e.g. you have to ensure that you are not > misinterpreting a shell exit code (e.g. checkfc could not be found or could > not be > executed) as the exit code of checkfc itself, and that you cleanly delineate > all > possible exit statuses of the program. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
