Description of problem: $ dnf install brltty-dracut $ dracut -f # needed to create the dir $ restorecon -Rvvn /var/lib/ Would relabel /var/lib/brltty from unconfined_u:object_r:var_lib_t:s0 to unconfined_u:object_r:brltty_var_lib_t:s0 I've added and audit watch rule prior to the directory being created: type=PATH msg=audit(1642598013.580:95): item=1 name="/var/lib/brltty" inode=67533312 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:var_lib_t:s0 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1642598013.580:95): item=0 name="/var/lib/" inode=134 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_lib_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(1642598013.580:95): cwd="/root" type=SYSCALL msg=audit(1642598013.580:95): arch=c000003e syscall=83 success=yes exit=0 a0=562b35b31800 a1=1fd a2=562b35b31 a3=0 items=2 ppid=3629 pid=3630 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="brltty" exe="/usr/bin/brltty" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="testwatch" not sure if it helps in identifying the process context. Version-Release number of selected component (if applicable): selinux-policy-34.1.22-1.el9
Jarku, brltty-dracut seems to use /var/lib/brltty, but it is not in the package. Would it be possible to include it so that the directory is created at install time?
(In reply to Zdenek Pytela from comment #1) > Jarku, > > brltty-dracut seems to use /var/lib/brltty, but it is not in the package. > Would it be possible to include it so that the directory is created at > install time? It's created by the brltty binary which is called from the dracut. I think the directory should be provided by the brltty package, otherwise there will be leftover directory (upon brltty uninstallation). Interesting that nobody noticed so far.
Fixed in the rawhide (f36).
Based on previous comments switching the component to assess the resolution for RHEL 9, too.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.