Backing out of changes to file contexts specification

[Al Pacifico]

This is related to the daemon question I asked earlier.

I created a problem using policygentool by specifying that a log file is
written to by two different binaries with different policies. My thread
about "Helper program for a daemon" provides some context (no pun intended).

I didn't realize that installing the policy would change the file context
specification database (although it makes perfect sense in retrospect). Now,
I've inadvertently specified that /var/log/slimserver be labelled under two
different contexts in /etc/selinux/targeted/contexts/files/file_contexts and
wish to remove the second set of entries.

Output of setfiles -n /etc/selinux/targeted/contexts/files/file_contexts
$filename includes several messages of the form:

/etc/selinux/targeted/contexts/files/file_contexts: Multiple different
specifications for /var/log/slimserver
(system_u:object_r:slimserver_scanner_var_log_t and
system_u:object_r:slimserver_var_log_t).

My policy module didn't install correctly because of this error, but the
file contexts specification is now incorrect. What is the best way to
correct this?
1. Just use sed or vi to eliminate the second specification?
2.Remove both installed policies that I wrote (which are the only non-stock
policy modules installed on my FC5 box) using semodule and restore
/etc/selinux/targeted/contexts/files/file_contexts from the rpm package
file?

Keep in mind I'm doing this over ssh to a box with no GUI, so I must use the
command line, vi, etc.
-al

[Daniel J Walsh]

Al Pacifico wrote:
> This is related to the daemon question I asked earlier.
>
> I created a problem using policygentool by specifying that a log file 
> is written to by two different binaries with different policies. My 
> thread about "Helper program for a daemon" provides some context (no 
> pun intended).
>
> I didn't realize that installing the policy would change the file 
> context specification database (although it makes perfect sense in 
> retrospect). Now, I've inadvertently specified that 
> /var/log/slimserver be labelled under two different contexts in 
> /etc/selinux/targeted/contexts/files/file_contexts and wish to remove 
> the second set of entries.
>
> Output of setfiles -n 
> /etc/selinux/targeted/contexts/files/file_contexts $filename includes 
> several messages of the form:
>
> /etc/selinux/targeted/contexts/files/file_contexts: Multiple different 
> specifications for /var/log/slimserver  
> (system_u:object_r:slimserver_scanner_var_log_t and 
> system_u:object_r:slimserver_var_log_t).
>
> My policy module didn't install correctly because of this error, but 
> the file contexts specification is now incorrect. What is the best way 
> to correct this?
> Just use sed or vi to eliminate the second specification?
>
> 2.Remove both installed policies that I wrote (which are the only 
> non-stock policy modules installed on my FC5 box) using semodule and 
> restore /etc/selinux/targeted/contexts/files/file_contexts from the 
> rpm package file?
>
> Keep in mind I'm doing this over ssh to a box with no GUI, so I must 
> use the command line, vi, etc.

semanage fcontext -d /var/log/slimserver
> -al
>
> Al Pacifico
> Seattle, WA
>
> --
> fedora-selinux-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Al Pacifico]

On 4/23/07, Daniel J Walsh  wrote:
> Al Pacifico wrote:
> > This is related to the daemon question I asked earlier.
> >
> > I created a problem using policygentool by specifying that a log file
> > is written to by two different binaries with different policies. My
> > thread about "Helper program for a daemon" provides some context (no
> > pun intended).
> >
> > I didn't realize that installing the policy would change the file
> > context specification database (although it makes perfect sense in
> > retrospect). Now, I've inadvertently specified that
> > /var/log/slimserver be labelled under two different contexts in
> > /etc/selinux/targeted/contexts/files/file_contexts and wish to remove
> > the second set of entries.
> >
> > Output of setfiles -n
> > /etc/selinux/targeted/contexts/files/file_contexts $filename includes
> > several messages of the form:
> >
> > /etc/selinux/targeted/contexts/files/file_contexts: Multiple different
> > specifications for /var/log/slimserver
> > (system_u:object_r:slimserver_scanner_var_log_t and
> > system_u:object_r:slimserver_var_log_t).
> >
> > My policy module didn't install correctly because of this error, but
> > the file contexts specification is now incorrect. What is the best way
> > to correct this?
> > Just use sed or vi to eliminate the second specification?
> >
> > 2.Remove both installed policies that I wrote (which are the only
> > non-stock policy modules installed on my FC5 box) using semodule and
> > restore /etc/selinux/targeted/contexts/files/file_contexts from the
> > rpm package file?
> >
> > Keep in mind I'm doing this over ssh to a box with no GUI, so I must
> > use the command line, vi, etc.
>
> semanage fcontext -d /var/log/slimserver

If I reboot, does the file
/etc/selinux/targeted/contexts/files/file_contexts get automatically
rewritten? If so, where does the information that it's filled with come from
and what process rewrites it?
> -al
> > --
> > Al Pacifico
> > Seattle, WA
> >
> > --
> > fedora-selinux-list mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Daniel J Walsh]

Al Pacifico wrote:
> On 4/23/07, *Daniel J Walsh* <[e-mail] 
> > wrote:
> Al Pacifico wrote:
> > This is related to the daemon question I asked earlier.
> >
> > I created a problem using policygentool by specifying that a log
> file
> > is written to by two different binaries with different policies. My
> > thread about "Helper program for a daemon" provides some context (no
> > pun intended).
> >
> > I didn't realize that installing the policy would change the file
> > context specification database (although it makes perfect sense in
> > retrospect). Now, I've inadvertently specified that
> > /var/log/slimserver be labelled under two different contexts in
> > /etc/selinux/targeted/contexts/files/file_contexts and wish to
> remove
> > the second set of entries.
> >
> > Output of setfiles -n
> > /etc/selinux/targeted/contexts/files/file_contexts $filename
> includes
> > several messages of the form:
> >
> > /etc/selinux/targeted/contexts/files/file_contexts: Multiple
> different
> > specifications for /var/log/slimserver
> > (system_u:object_r:slimserver_scanner_var_log_t and
> > system_u:object_r:slimserver_var_log_t).
> >
> > My policy module didn't install correctly because of this error,
> but
> > the file contexts specification is now incorrect. What is the
> best way
> > to correct this?
> > 1. Just use sed or vi to eliminate the second specification?
> > 2.Remove both installed policies that I wrote (which are the only
> > non-stock policy modules installed on my FC5 box) using semodule and
> > restore /etc/selinux/targeted/contexts/files/file_contexts from the
> > rpm package file?
> >
> > Keep in mind I'm doing this over ssh to a box with no GUI, so I
> must
> > use the command line, vi, etc.
> semanage fcontext -d /var/log/slimserver
>
>
> If I reboot, does the file 
> /etc/selinux/targeted/contexts/files/file_contexts get automatically 
> rewritten? If so, where does the information that it's filled with 
> come from and what process rewrites it?

No, Only time these files get modified is by the semanage or semodule 
command.  (rpm installations, often execute these commands. )  All the 
data used to build this file is in /etc/selinux/targeted/modules/active/
> > -al
> > --
> > Al Pacifico
> > Seattle, WA
> >
> ------------------------------------------------------------------------
>
> >
> > --
> > fedora-selinux-list mailing list
> > [e-mail]
> <mailto:[e-mail]>
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>
>
>
> -- 
> Al Pacifico
> Seattle, WA

[Stephen Smalley]

On Mon, 2007-04-23 at 08:20 -0700, Al Pacifico wrote:
> If I reboot, does the
> file /etc/selinux/targeted/contexts/files/file_contexts get
> automatically rewritten? If so, where does the information that it's
> filled with come from and what process rewrites it?

It doesn't get rewritten at boot, only upon a change made to the policy
via semodule or semanage (both of which use libsemanage as their
backend).  libsemanage manages a private store
under /etc/selinux/targeted/modules, applies all changes in a sandbox
there first, and then installs to the real locations upon a successful
completion of a transaction.