Bug 1398427

Correction, the Version-Release number should be:

	policycoreutils-python-2.5-9.el7.x86_64


This issue is present following the 7.3 rebase of libsemanage due to the following upstream commit.

	Properly build the swig exception file even if the headers are missing

	During build if the headers are not installed in the system path, the
	generated swig exception (.i) file might be empty.

	https://github.com/SELinuxProject/selinux/commit/9792099fd7847266377df151e7738f9b38ffc18d


Prior to the above commit, the following codepath acted as expected:

/usr/lib/python2.7/site-packages/seobject/__init__.py
<snip>
class fcontextRecords(semanageRecords):
<snip>
        def __modify(self, target, setype, ftype, serange, seuser):
<snip>
                (rc, exists) = semanage_fcontext_exists(self.sh, k)
                if rc < 0:
                        raise ValueError(_("Could not check if file context for %s is defined") % target)
                if not exists:
                       (rc, exists) = semanage_fcontext_exists_local(self.sh, k)
                       if not exists:
                              raise ValueError(_("File context for %s is not defined") % target)

                (rc, fcontext) = semanage_fcontext_query_local(self.sh, k)
                if rc < 0:
                       (rc, fcontext) = semanage_fcontext_query(self.sh, k)
                       if rc < 0:
                              raise ValueError(_("Could not query file context for %s") % target)


The semanage_fcontext_query_local() operation would return -1, and it would fall through to the secondary semanage_fcontext_query(). However, with the upstream commit included, the first "file_contexts.local" lookup returns an "OSError" python exception.

Kyle Walker
Software Maintenance Engineer - SEG
North America

semanage fcontext -m ... should return similar error message as is returned when you try to delete the fcontext pattern:

# semanage fcontext -d -t httpd_log_t "/var/opt/quest/vas/vasd(/.*)?"
ValueError: File context for /var/opt/quest/vas/vasd(/.*)? is defined in policy, cannot be deleted

For example:
File context for /var/opt/quest/vas/vasd(/.*)? is defined in policy, cannot be modified

(In reply to Milos Malik from comment #4)
> semanage fcontext -m ... should return similar error message as is returned
> when you try to delete the fcontext pattern:
> 
> # semanage fcontext -d -t httpd_log_t "/var/opt/quest/vas/vasd(/.*)?"
> ValueError: File context for /var/opt/quest/vas/vasd(/.*)? is defined in
> policy, cannot be deleted
> 
> For example:
> File context for /var/opt/quest/vas/vasd(/.*)? is defined in policy, cannot
> be modified

Can you elaborate as to why this is the case? I mean, it doesn't do that anyways. Beyond that, it seems well beyond sub-optimal to cause base policy fcontexts to be impossible to alter.

- Kyle Walker

I always thought that fcontext patterns defined in policy cannot be changed, but I would appreciate if they could be overriden locally via semanage.

Kyle, thanks for the investigation. I was wrong this problem.

The patch. It looks good to me and I'd like to resend it upstream if you agree.

Petr,

Sounds good to me! Unless you would like me to push the patch upstream myself. Either way works for me.

- Kyle Walker

*** Bug 1401699 has been marked as a duplicate of this bug. ***

I are you sure this is fully fixed?

On a centos, when doing semanage fcontext -m -t httpd_config_t "/var/opt/quest/vas/vasd(/.*)?"

I get: "ValueError: File context for /var/opt/quest/vas/vasd(/.*)? is not defined"

What version do you use? This is supposed to be fixed in policycoreutils-2.5-11.el7_3 which hasn't been released yet.

Argh, nevermind, the package has not been updated yet in CentOS

I have verified this is fixed on Atomic Host 7.3.2 with policycoreutils-python-2.5-11.el7_3.x86_64


# semanage fcontext -a -t svirt_sandbox_file_t "/var/lib/kubelet(/.*)?"
libsemanage.dbase_llist_query: could not query record value (No such file or directory).
[root@atomic-7 ~]# echo $?
0


Thanks!
~james

This bug should go through regular QE testing. Switching back to ON_QA.

*** Bug 1396902 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1883