wanted to follow up on this thread so anyone in the future searching for
a solution to this problem can find this.
basically, i'm installing a brand new system in a chroot environment.
one of our steps to complete the setup requires adding some custom file
contexts, and so I ran a command like:
chroot /mnt/root semanage fcontext -a -t auditd_log_t "/audit(/.*)?"
So, the curious thing is that I thought this command succeeded because I
was able to find the file:
/mnt/root/etc/selinux/targeted/contexts/files/file_contexts.local
But it turns out that file should not have been there as the semanage
command above fails (exit status = 1) and should have rolled back what
it was attempting to do. This appears to be a bug in my conversations
with Stephen Smalley.
The reason why semanage fails is because I don't have /selinux in the
chroot environment, and semanage tries to reload the policy and can't
and then fails. However, it doesn't make sense for semanage to reload
the policy of the "host" since the command is meant to make changes to
the chroot environment of another system i'm installing. Turns out, the
solution is to use the -N (--noreload) option in semanage:
chroot /mnt/root semanage fcontext -a -N -t auditd_log_t "/audit(/.*)?"
This appears to do the job right and the problem I had that started this
thread is no longer.
Hope that helps someone..
-Bond
On 08/26/2015 05:55 AM, Stephen Smalley wrote:
On 08/25/2015 06:46 PM, Bond Masuda wrote:
On 08/24/2015 01:09 PM, Stephen Smalley wrote:
On 08/24/2015 02:22 PM, Bond Masuda wrote:
On 08/24/2015 11:15 AM, Stephen Smalley wrote:
On 08/17/2015 07:42 PM, Bond Masuda wrote:
We want to add some custom file contexts for certain directories, in
particular we have /audit as a separate partition and run this:
To make sure auditd works. This is run with chroot because the system
we're modifying is not running and mounted at /mnt/root. This creates
the file_contexts.local file with this content:
# This file is auto-generated by libsemanage
# Do not edit directly.
/audit(/.*)? system_u:object_r:auditd_log_t:s0
Later on, when we boot that system that was in /mnt/root, the
file_contexts.local remains the same. However, if I run semanage to add
another record, for example (this time, not in chroot):
semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
It creates the content for httpd_sys_content_t in file_contexts.local,
but overwrites the previous entry for auditd_log_t.
If I add the auditd_log_t entry once again, _both_ entries are now
present in file_contexts.local. So, it seems that the 1st time I run
semanage fcontext -a _while_ the system is running, it is not aware of
the content that was added when I ran semanage fcontext -a when the
system was offline and mounted in /mnt/root.
Does semanage maintain state somewhere other than in the
file_contexts.local file? How can I make sure it is aware of the content
in file_contexts.local that was created by semanage when it was run in
chroot?
This sounds like a bug to me. What version of libsemanage and
policycoreutils are you using, as this may be version-specific?
The versions are:
libsemanage-2.0.43-5.1.el6.x86_64
libsemanage-python-2.0.43-5.1.el6.x86_64
policycoreutils-2.0.83-24.el6.x86_64
policycoreutils-python-2.0.83-24.el6.x86_64
So in that case, I'd expect that each semanage fcontext -a command would
generate a file_contexts.local file under
/etc/selinux/targeted/modules/active/ and under
/etc/selinux/targeted/contexts/files/. The first one is the private
copy generated and used within the policy module store only, and the
latter is the public copy installed at the end of the transaction and
used by other programs like restorecon to look up file labels. They
should be identical at the end of the semanage command.
Is this reproducible? If so, it would be interesting the compare the
two files before and after each of the semanage commands you ran.
Stephen,
Thanks for the info above. I didn't know the information was in two
places. When running the semanage command in chroot to /mnt/root, I get
a file in
/mnt/root/etc/selinux/targeted/contexts/files/file_contexts.local, but I
do *NOT* get /mnt/root/etc/selinux/targeted/modules/active. The contents
of the "active" directory are:
[root@localhost active]# ls -al
total 9052
drwx------. 3 root root 4096 Aug 25 14:35 .
drwxr-xr-x. 3 root root 70 Aug 25 14:36 ..
-rw-------. 1 root root 249117 Aug 25 14:35 base.pp
-rw-------. 1 root root 32 Aug 25 14:35 commit_num
-rw-------. 1 root root 290786 Aug 25 14:35 file_contexts
-rw-r--r--. 1 root root 6405 Aug 25 14:35 file_contexts.homedirs
-rw-------. 1 root root 296417 Aug 25 14:35 file_contexts.template
-rw-------. 1 root root 5631 Aug 25 14:35 homedir_template
drwx------. 2 root root 8192 Aug 25 14:35 modules
-rw-------. 1 root root 0 Aug 25 14:35 netfilter_contexts
-rw-r--r--. 1 root root 8380527 Aug 25 14:35 policy.kern
-rw-------. 1 root root 106 Aug 25 14:35 seusers.final
-rw-------. 1 root root 101 Aug 25 14:35 users_extra
The contents of the "files" directory are:
[root@localhost files]# ls -al
total 304
drwxr-xr-x. 2 root root 93 Aug 25 14:36 .
drwxr-xr-x. 4 root root 4096 Aug 25 14:36 ..
-rw-r--r--. 1 root root 290786 Aug 25 14:36 file_contexts
-rw-r--r--. 1 root root 6405 Aug 25 14:36 file_contexts.homedirs
-rw-r--r--. 1 root root 120 Aug 25 14:36 file_contexts.local
-rw-r--r--. 1 root root 139 Aug 13 02:37 media
So, is this a bug? Or, intended behavior due to some condition of
running semanage in chroot?
It sounds like a bug. However, I can't reproduce it. How did you set up
your chroot environment, including how are you handling /proc and
/selinux within the chroot?
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
