Find if permission denied errors are caused by SELinux for VeryUtils Java PDF Toolkit (jpdfkit) software.
VeryUtils Java PDF Toolkit (jpdfkit) can run on Linux systems, VeryUtils Java PDF Toolkit (jpdfkit) can be downloaded from following web page,
https://veryutils.com/java-pdf-toolkit-jpdfkit
However, we recently noticed an issue where we used the following command line to encrypt PDF files on SUSE Linux system,
java -jar /Encrypt-PDF/jpdfkit_1/jpdfkit.jar /Encrypt-PDF/jpdfkit_1/Manual.pdf output /Encrypt-PDF/jpdfkit_1/Manual-output.pdf owner_pw 123 user_pw 456 encrypt_128bit allow printing
The encrypted PDF file couldn't be opened because permission denied problem, even if we tried to copy encrypted PDF file to another file, we still encounter permission denied problem,
cp /Encrypt-PDF/jpdfkit_1/Manual-output.pdf /Encrypt-PDF/jpdfkit_1/Manual-output2.pdf
After we researched this problem for some days, we sure this problem caused by "SELinux" in Linux system, here is the solution.
SELinux, short for Security Enhanced Linux, is a Linux security module that is part of many Linux server distributions. While SELinux increases server security (despite being created by NSA), it often results in some unexpected access/permission denied errors.
If you get one of such errors on a server with SELinux enabled, and there are no obvious file permission issues, you should check if the issue is caused by SELinux. To check the status of SELinux, run:
sestatus
You should get something like this:
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
"Current mode: enforcing" indicates that SELinux is running.
To temporary disable SELinux, run:
setenforce 0
If this resolves the problem, and you no longer get "permission denied" errors, it means the issue was caused by SELinux. Re-enable it with setenforce 1 and try to find the root cause.
To help with troubleshooting, you can check SELinux log files located in /var/log/audit/audit.log
Very often, the issue is caused by incorrect security context (also called security label) assigned to the affected files or folders. To view security context that SELinux has applied to files or folders, run one of the following commands (they all display security contexts, just in different formats):
ls -Z or ls --context
ls --lcontext
ls --scontext
To modify the security context, you can use chcon command, i.e:
chcon -R -t httpd_sys_content_t /www/sites
httpd_sys_content_t - Apache Read-Only access
httpd_sys_rw_content_t - Apache Read/Write access
httpd_log_t - Apache log files
httpd_cache_t - Apache caching
or use reference directory:
chcon -R --reference=/var/www/html /www/sites