Bug 1396902 - semanage reports error "libsemanage.dbase_llist_query: could not query record value (No such file or directory)"
Summary: semanage reports error "libsemanage.dbase_llist_query: could not query record...
Keywords:
Status: CLOSED DUPLICATE of bug 1398427
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: policycoreutils
Version: 7.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 7.4
Assignee: Petr Lautrbach
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-21 06:21 UTC by Supreet
Modified: 2020-01-17 16:12 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1397713 (view as bug list)
Environment:
Last Closed: 2017-03-03 11:27:28 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Supreet 2016-11-21 06:21:06 UTC
Description of problem:

When we change the location of the log directory we do have to (re)set the file contexts and that is what (and why) Puppet does for us.
Since a recent upgrade of some selinux packages like "policycoreutils" and "policycoreutils-python" for example, the behaviour of "semanage -a -t ..." changed, resulting in the error message.

[root@dinodevapp64 ~]# rpm -qa | grep -i policycoreutils
policycoreutils-2.5-8.el7.x86_64
policycoreutils-python-2.5-8.el7.x86_64

For now we've removed the Puppet code responsible for (re)setting the selinux file contexts, but we like to know why.

Version-Release number of selected component (if applicable):


How reproducible:

[0] 15:27 root rhel72-1.brq ~ # rpm -qa | grep httpd
httpd-2.4.6-45.el7.x86_64
httpd-tools-2.4.6-45.el7.x86_64
[0] 15:27 root rhel72-1.brq ~ # systemctl status httpd.service
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:httpd(8)
           man:apachectl(8)
[3] 15:27 root rhel72-1.brq ~ # ls -ldZ /var/log/httpd/
drwx------ root root ?                                /var/log/httpd/

[0] 15:30 root rhel72-1.brq ~ # semanage fcontext -l | grep '^/var/log/httpd'
/var/log/httpd(/.*)?                               all files          system_u:object_r:httpd_log_t:s0 


[2] 15:31 root rhel72-1.brq ~ # semanage fcontext -a -t 'httpd_log_t' '/var/log/httpd(/.*)?'
libsemanage.dbase_llist_query: could not query record value (No such file or directory).
OSError: No such file or directory
[1] 15:31 root rhel72-1.brq ~ # 

Evenif the service is started then also we are still getting the same error.

Additional info:

It is allowing for other sub-directories but not for httpd
==========================
[root@test ~]# mkdir /var/log/httpd_test

[root@test ~]# semanage fcontext -a -t 'httpd_log_t' '/var/log/httpd_test(/.*)?'

[root@test ~]# ls -alZ /var/log/httpd_test/
drwxr-xr-x. root root unconfined_u:object_r:var_log_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_log_t:s0   ..

[root@test ~]# restorecon /var/log/httpd_test

[root@test ~]# ls -alZ /var/log/httpd_test/
drwxr-xr-x. root root unconfined_u:object_r:httpd_log_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_log_t:s0   ..

[root@test ~]# semanage fcontext -a -t 'httpd_log_t' '/var/log/httpd_test(/.*)?'


[root@test ~]# matchpathcon /var/log/httpd*
/var/log/httpd  system_u:object_r:httpd_log_t:s0
/var/log/httpd_test     system_u:object_r:httpd_log_t:s0

[root@test ~]# semanage fcontext -d '/var/log/httpd_test(/.*)?'
==========================

Comment 5 Petr Lautrbach 2016-11-21 12:52:09 UTC
The description of this bug talks about /var/log/httpd while the customer case uses /data/htdocs.

However the cause is most likely the same. You can't add a file context rule which is already defined in the policy. And as far as I know it hasn't changed since RHEL-7.0 GA

[root@plautrba-rhel-72 ~]# rpm -q libsemanage
libsemanage-2.1.10-18.el7.x86_64

[root@plautrba-rhel-72 ~]# semanage fcontext -a -t 'httpd_log_t' '/var/log/httpd(/.*)?'
libsemanage.dbase_llist_query: could not query record value (No such file or directory).


'/var/log/httpd(/.*)?' is defined in apache module shipped by selinux-policy-targeted.

'/data/htdocs(/.*)?' could be defined in some local SELinux module installed by the customer.


On the other hand, if a file contexts rule was added as a local modification using 'semanage fcontext -a', you can change it all the time. When the rule already exists in local modifications, '-a' option works like '-m' option so the rule is changed.

Comment 6 Petr Lautrbach 2016-11-21 12:53:35 UTC
The problem is the error message which is more confusing than helpful.

Comment 7 Supreet 2016-11-22 05:19:37 UTC
Hello Petr,

The issue is not with /data/htdocs(/.*)? but only with /var/log/httpd(/.*)?' which gives the error : libsemanage.dbase_llist_query: could not query record value (No such file or directory).

Comment 8 Petr Lautrbach 2016-11-22 11:47:01 UTC
 Supreet,

the '/var/log/httpd(/.*)?' file context rule is defined in the system policy in apache module and you can't add or change the same specification using 'semanage fcontext' which is already defined in policy.

If you really need to change the label on /var/log/httpd - why? - then you need to modify the apache module and install it with a higher priority. While I don't think it's a good idea I wrote this article https://blog-bachradsusi.rhcloud.com/2015/06/05/selinux-modules-priority/ which describes similar solution.

You can change labels for files and directories inside /var/log/httpd using this pattern '/var/log/httpd/.*' which is different from the policy pattern and is more specific so it will be applied instead the policy one.

As I wrote in comment #c6 - the error message is quite confusing in this case.

Comment 10 Petr Lautrbach 2016-11-29 09:41:59 UTC
I was wrong. There's a bug in policycoreutils. For the more information see https://bugzilla.redhat.com/show_bug.cgi?id=1398427

Comment 14 Petr Lautrbach 2017-03-03 11:27:28 UTC

*** This bug has been marked as a duplicate of bug 1398427 ***


Note You need to log in before you can comment on or make changes to this bug.