/usr/lib/jvm/java(.*/)bin(/.*)? uses misleading parentheses around
".*/". In some cases, a pattern with (.*/) is a mispelling to (.*/)?,
but not here (/usr/lib/jvm/javabin/ never exists).
Moreover, using .* here is right, as the pattern matches the content of
subdirectories of /usr/lib/jvm/ which names are prefixed by java. More
precisely, the pattern matches for example:
- programs in /usr/lib/jvm/java-10-openjdk/bin
- programs in /usr/lib/jvm/java-8-openjdk/jre/bin
In the end, the pattern does not have any error, but the parentheses are
misleading. Remove them.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
The following pattern seems to match much more than intended:
/usr/(.*/)?bin/java[^-]*
According to the commit which introduced it
(0190325c18),
the aim was to match java1.4, java5, java6, and not java-config nor
java-check-environment. The issue is that the pattern also matches
sub-directories such as:
/usr/share/my-application/bin/java/myfile
Prevent this by adding / in the character blacklist of the pattern.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Additional java context
unconfined_Java apps needs to execmod any file since we do not know where the jave content will be labeled
We want unconfined java apps to transition to rpm when they execute rpm_exec_t. To maintain proper labeling.
Some file_contexts regular expressions in refpolicy-strict are causing
genhomedircon to die; refpolicy is failing to build for me entirely.
The regular expressions seem redundant to me, perhaps I am missing
something, but the following patch fixes the problems for me. Please
review and apply
