10:07 a.m.
Having trouble with default file contexts again.
I have a policy module with the following .fc file:
/home/pgsql -d
gen_context(system_u:object_r:var_lib_t,s0)
/home/pgsql/data -d
gen_context(system_u:object_r:postgresql_db_t,s0)
/home/pgsql/data/.* -d
gen_context(system_u:object_r:postgresql_db_t,s0)
/home/pgsql/data/.* --
gen_context(system_u:object_r:postgresql_db_t,s0)
/home/pgsql/pgstartup\.log --
gen_context(system_u:object_r:postgresql_log_t,s0)
The entries that are not regexes work OK, but as soon as I use a regex,
the type I'm specifying gets overridden by user_home_t when I do a
restorecon.
For instance, if I have a file /home/pgsql/data/test.db, restorecon
labels it user_home_t rather than postgresql_db_t.
/home/pgsql is not the home directory of any user.
Why is this happening?
It appears that some further tweaking to the file contexts sort order
that I put on the wiki
(http://fedoraproject.org/wiki/SELinux/ManagingFileContext) after the
last discussion is needed.
Paul.
10:52 a.m.
On Wed, 2006-05-31 at 16:07 +0100, Paul Howarth wrote:
Having trouble with default file contexts again.
I have a policy module with the following .fc file:
/home/pgsql -d
gen_context(system_u:object_r:var_lib_t,s0)
/home/pgsql/data -d
gen_context(system_u:object_r:postgresql_db_t,s0)
/home/pgsql/data/.* -d
gen_context(system_u:object_r:postgresql_db_t,s0)
/home/pgsql/data/.* --
gen_context(system_u:object_r:postgresql_db_t,s0)
/home/pgsql/pgstartup\.log --
gen_context(system_u:object_r:postgresql_log_t,s0)
The entries that are not regexes work OK, but as soon as I use a
regex,
the type I'm specifying gets overridden by user_home_t when I do a
restorecon.
For instance, if I have a file /home/pgsql/data/test.db, restorecon
labels it user_home_t rather than postgresql_db_t.
/home/pgsql is not the home directory of any user.
Why is this happening?
When the file contexts are sorted, we need a way to split out some in a
per-user way. If a path has the prefix keyword HOME_DIR, HOME_ROOT, or
ROLE, the context specification is split out into the homedir.template
file.
Example:
HOME_DIR/.+ user_u:object_r:user_home_t:s0
(I briefly mentioned this split in a prior post, but I should have been
more clear about it; sorry about that.)
This template file is used to produce file contexts for each selinux
user. These per-user file contexts are written to the file
"file_contexts.homedirs", which lives in the same directory as
"file_contexts".
When matching file contexts, the file_contexts.homedirs contexts are
appended to the main file_contexts contexts, so they have priority.
The contexts for user user_u include:
/home/[^/]*/.+ user_u:object_r:user_home_t:s0
/home/[^/]* -d user_u:object_r:user_home_dir_t:s0
which is why your file is getting that context, even though you do not
have an actual user with the home directory /home/pgsql.
You can prefix your file context path expression with a template keyword
to place it in the file_context.homedirs file.
Chris
11 a.m.
Christopher Ashworth wrote:
On Wed, 2006-05-31 at 16:07 +0100, Paul Howarth wrote:
> Having trouble with default file contexts again.
>
> I have a policy module with the following .fc file:
>
> /home/pgsql -d
> gen_context(system_u:object_r:var_lib_t,s0)
> /home/pgsql/data -d
> gen_context(system_u:object_r:postgresql_db_t,s0)
> /home/pgsql/data/.* -d
> gen_context(system_u:object_r:postgresql_db_t,s0)
> /home/pgsql/data/.* --
> gen_context(system_u:object_r:postgresql_db_t,s0)
> /home/pgsql/pgstartup\.log --
> gen_context(system_u:object_r:postgresql_log_t,s0)
> The entries that are not regexes work OK, but as soon as I use a regex,
> the type I'm specifying gets overridden by user_home_t when I do a
> restorecon.
>
> For instance, if I have a file /home/pgsql/data/test.db, restorecon
> labels it user_home_t rather than postgresql_db_t.
>
> /home/pgsql is not the home directory of any user.
>
> Why is this happening?
When the file contexts are sorted, we need a way to split out some in a
per-user way. If a path has the prefix keyword HOME_DIR, HOME_ROOT, or
ROLE, the context specification is split out into the homedir.template
file.
Example:
HOME_DIR/.+ user_u:object_r:user_home_t:s0
(I briefly mentioned this split in a prior post, but I should have been
more clear about it; sorry about that.)
This template file is used to produce file contexts for each selinux
user. These per-user file contexts are written to the file
"file_contexts.homedirs", which lives in the same directory as
"file_contexts".
Yes, I found that.
When matching file contexts, the file_contexts.homedirs contexts are
appended to the main file_contexts contexts, so they have priority.
Is there some reason why "semanage fcontext -l" does not include these?
The contexts for user user_u include:
/home/[^/]*/.+ user_u:object_r:user_home_t:s0
/home/[^/]* -d user_u:object_r:user_home_dir_t:s0
which is why your file is getting that context, even though you do not
have an actual user with the home directory /home/pgsql.
I thought they'd only have priority by means of their position at the
end of the list if all other sorting criteria were equal? So the fact
that /home/pgsql/data(/.*)? for instance has a longer stem than
/home/[^/]*/.+ should have given it precedence?
You can prefix your file context path expression with a template
keyword
to place it in the file_context.homedirs file.
Wouldn't that result in all /home/*/data directories and everything
underneath them being labelled postgresql_db_t, not just /home/pgsql/data?
Paul.
11:44 a.m.
On Wed, 2006-05-31 at 17:00 +0100, Paul Howarth wrote:
> When matching file contexts, the file_contexts.homedirs contexts
are
> appended to the main file_contexts contexts, so they have priority.
Is there some reason why "semanage fcontext -l" does not include these?
Hmmm...I don't know off the top of my head--it certainly doesn't sound
like desirable behavior. Anyone who's been around longer than me know
if this is desired or a bug? I'll look to see where the homedirs are
omitted during the listing by libsemange.
> The contexts for user user_u include:
>
> /home/[^/]*/.+ user_u:object_r:user_home_t:s0
> /home/[^/]* -d user_u:object_r:user_home_dir_t:s0
>
> which is why your file is getting that context, even though you do not
> have an actual user with the home directory /home/pgsql.
I thought they'd only have priority by means of their position at the
end of the list if all other sorting criteria were equal? So the fact
that /home/pgsql/data(/.*)? for instance has a longer stem than
/home/[^/]*/.+ should have given it precedence?
Once the sort is done during the original generation of the files, and
the files have been spit out, no additional sorting occurs. So sticking
the homedirs contexts at the end of the list when looking for a match
means that every homedir context is checked for a match first, before
any other context is checked.
> You can prefix your file context path expression with a template
keyword
> to place it in the file_context.homedirs file.
Wouldn't that result in all /home/*/data directories and everything
underneath them being labelled postgresql_db_t, not just /home/pgsql/data?
Yes, you are right. Unfortunately, I don't think there is any way
around this at the moment. Anything with the "/home/" prefix will get
caught by the per-user contexts, and so trying to label files below
"/home/" in a non-per-user way (for lack of a better term), won't work.
As I understand it, you'll have to move it to a different location.
Chris
11:50 a.m.
Christopher Ashworth wrote:
On Wed, 2006-05-31 at 17:00 +0100, Paul Howarth wrote:
>> When matching file contexts, the file_contexts.homedirs contexts are
>> appended to the main file_contexts contexts, so they have priority.
> Is there some reason why "semanage fcontext -l" does not include these?
Hmmm...I don't know off the top of my head--it certainly doesn't sound
like desirable behavior. Anyone who's been around longer than me know
if this is desired or a bug? I'll look to see where the homedirs are
omitted during the listing by libsemange.
Thanks.
>> The contexts for user user_u include:
>>
>> /home/[^/]*/.+ user_u:object_r:user_home_t:s0
>> /home/[^/]* -d user_u:object_r:user_home_dir_t:s0
>>
>> which is why your file is getting that context, even though you do not
>> have an actual user with the home directory /home/pgsql.
> I thought they'd only have priority by means of their position at the
> end of the list if all other sorting criteria were equal? So the fact
> that /home/pgsql/data(/.*)? for instance has a longer stem than
> /home/[^/]*/.+ should have given it precedence?
Once the sort is done during the original generation of the files, and
the files have been spit out, no additional sorting occurs. So sticking
the homedirs contexts at the end of the list when looking for a match
means that every homedir context is checked for a match first, before
any other context is checked.
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.
>> You can prefix your file context path expression with a
template keyword
>> to place it in the file_context.homedirs file.
> Wouldn't that result in all /home/*/data directories and everything
> underneath them being labelled postgresql_db_t, not just /home/pgsql/data?
Yes, you are right. Unfortunately, I don't think there is any way
around this at the moment. Anything with the "/home/" prefix will get
caught by the per-user contexts, and so trying to label files below
"/home/" in a non-per-user way (for lack of a better term), won't work.
As I understand it, you'll have to move it to a different location.
Actually this isn't my problem - I'm trying to help someone else. If it
was me I'd just bind mount /home/pgsql on /var/lib/pgsql and there
wouldn't be an issue...
Paul.
11:54 a.m.
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.
Chris
12:05 p.m.
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.
--
Stephen Smalley
National Security Agency
12:58 p.m.
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.
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.
Chris
1:19 p.m.
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.
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.
--
Stephen Smalley
National Security Agency
1:32 p.m.
On Wed, 2006-05-31 at 11:52 -0400, Christopher Ashworth wrote:
Example:
HOME_DIR/.+ user_u:object_r:user_home_t:s0
Also, I need to correct the above example.
It should read:
HOME_DIR/.+ system_u:object_r:user_home_t:s0
because genhomedircon replaces "system_u" with the proper user while
generating file_contexts.homedirs. Sorry for the typo.
Chris
6:08 a.m.
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?
> 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?
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?
Paul.
7:38 a.m.
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
6539
days inactive
6540
days old
selinux@lists.fedoraproject.org
11 comments
3 participants
participants (3)
-
Christopher Ashworth -
Paul Howarth -
Stephen Smalley