On Thu, 2006-06-01 at 12:08 +0100, Paul Howarth wrote: > Stephen Smalley wrote: > > On Wed, 2006-05-31 at 13:58 -0400, Christopher Ashworth wrote: > >> On Wed, 2006-05-31 at 13:05 -0400, Stephen Smalley wrote: > >>> On Wed, 2006-05-31 at 12:54 -0400, Christopher Ashworth wrote: > >>>> On Wed, 2006-05-31 at 17:50 +0100, Paul Howarth wrote: > >>>>> Hmm, that doesn't explain why file contexts that aren't regexes do > >>>>> actually work. So if I have: > >>>>> > >>>>> /home/pgsql/pgstartup\.log -- > >>>>> gen_context(system_u:object_r:postgresql_log_t,s0) > >>>>> > >>>>> this actually works as expected, even though the /home/[^/]*/.+ > >>>>> homedir context also matches. > >>>> Ah, true. I forgot you had said that this behavior was occurring. It > >>>> seems I have misremembered what is happening. Let me look again to > >>>> confirm what's going on. > >>> libselinux gives precedence to fully specified pathnames (no regex > >>> characters). Doesn't matter where they fall within the config files. > >> Ah, right; thanks. (As specified in libselinux/src/matchpathcon.c) > >> > >> So what I said before was true, modulo the fact that when the actual > >> call to matchpathcon is made, one final sort is performed, to give fully > >> specified pathnames precedence. > > Is there some reason why this final sort is only done for > fully-specified pathnames and doesn't use the same comparison function > as lower down in the hierarchy? This is essentially just a legacy issue - the libselinux ordering of the multiple separate file_contexts sources and sorting of fully specified entries all predates the libsemanage ordering and sorting, and not everyone is necessarily using managed policy via libsemanage. We also have a strange side effect of the current handling of local file contexts vs. homedirs, as the pre-merging of local file contexts by libsemanage alters its effective priority relative to homedirs compared to the legacy logic in libselinux. > >> Seems like the end-to-end process is a bit confusing, what with several > >> layers of sorting going on, but I can't immediately suggest an > >> improvement. I guess it's just a matter of documenting the life of file > >> contexts as clearly as possible. > > > > Ultimately, we'd like to migrate all integration and ordering of the > > various file contexts sources into libsemanage and eliminate the need > > for it in libselinux. Mostly a legacy issue. > > So that would mean that the file contexts would be sorted in the order > previously discussed, no matter where their origin was (base policy, > semodule, semanage, homedir etc.)? That would be much clearer :) > > Whilst we're stuck with the existing ordering, is there a way to disable > generation of the homedir contexts, so that someone could then add the > contexts from file_contexts.homedirs to policy using semanage instead? I don't think so, at present. homedir_template is generated from the base file_contexts, so one would have to strip the template expressions from the base policy to cause it to be empty, which would presumably render genhomedircon a no-op. Doesn't appear to be a way to suppress genhomedircon invocation at present by libsemanage, or even a config option for it. > This shouldn't be too onerous for most users of targeted policy with > only user_u and root to worry about. The result would be a set of > contexts that obeyed the expected ordering rules, wouldn't it? -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
