[fixed] LibreSign v8.0.0-rc5 fails configuration check on settings page

[DazeEnd]

Describe the bug
After downloading Java, PDFtk, and JSignPdf, a status of "error" is shown in the "Configuration check" section of the LibreSign settings page.

To Reproduce

1. Start with fresh installation of Nextcloud 28.0.2

2. Copy libresign-v8.0.0-rc3.tar.gz to the apps directory, and uncompress it.

3. Fix ownership of libresign directory created in step 2: sudo chown -R apache:apache libresign/

4. Log into Nextcloud as the admin and activate the LibreSign app.

5. Open the LibreSign Settings page. Under the "Configuration check" heading, every status is set to "error". I expected this since I haven't installed any binaries yet.

6. From the command line, install Java, PDFtk, and JSignPdf:

[ceperry@newton public_html]$ pwd
/var/www/newton-test.relanet.com/nextcloud/public_html
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --java
Downloading java...
 46080826/46080826 [============================] 100%
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --pdftk
Downloading pdftk...
 31928448/31928448 [============================] 100%
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --jsignpdf
Downloading JSignPdf...
 19027694/19027694 [============================] 100%

7. Refresh LibreSign settings screen in the web browser. The status of Java, PDFtk, and JSignPdf are still set to "error".
   

8. Run occ libresign:configure:check. Thestatus of Java, PDFtk, and JSignPdf are set to 'success'.

[ceperry@newton public_html]$ pwd
/var/www/newton-test.relanet.com/nextcloud/public_html
[ceperry@newton public_html]$ sudo -u apache php occ libresign:configure:check
 --------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------- 
  Status    Resource            Message                                                                                                                                  Tip                                         
 --------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------- 
  success   java                Java version: openjdk version "17.0.5" 2022-10-18                                                                                                                                    
  success   java                Java binary: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/java/jdk-17.0.5+8-jre/bin/java                                               
  success   pdftk               PDFtk version: 3.3.3                                                                                                                                                                 
  success   pdftk               PDFtk path: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/pdftk                                                                         
  success   jsignpdf            JSignPdf version: 2.2.2                                                                                                                                                              
  success   jsignpdf            JSignPdf path: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/jsignpdf-2.2.2/JSignPdf.jar                                                
   error    openssl-configure   OpenSSL (root certificate) not configured.                                                                                               Run occ libresign:configure:openssl --help  
 --------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------- 

9. In the LibreSign settings page, click the "Download Binaries" button. After clicking, the button becomes "greyed out", the text of the button changes to "Downloading binaries", and a circular activity indicator begins spinning on the button.

10. After 15 minutes, the activity indicator on the button was still spinning, so I refreshed the settings page. After refreshing, the button text returned to "Download binaries", and all status listed under "Configuration check" were still set to "error".

Expected behavior
After installing the binaries, I expected the status on the settings page to change to "success". I also expected the "Download binaries" button to either actually download some binaries, or give an indication that the binaries have already been downloaded.

Screenshots
See above.

Environment information (please complete the following information):

• OS: AlmaLinux 8.9
• PHP: 8.2.15
• Apache: 2.4.37
• Browser: Chrome
• LibreSign Version: 8.0.0-rc3
• Nextcloud Server Version: 28.0.2
• Logs (get the entries from nextcloud.log related with LibreSign i.e tail -f data/nextcloud.log|grep libresign): No log entries contain the string "libresign".

Additional context
N/A

[vitormattos]

I used a similar environment here using Docker with this settings:

• OS: Debian GNU/Linux 12
• PHP: 8.2.16
• Apache: Apache/2.4.57
• Browser: Version 121.0.6167.184 (Official Build) (64-bit)
• LibreSign Version: 8.0.0-rc3 (from here: https://github.com/LibreSign/libresign/releases/download/v8.0.0-rc3/libresign-v8.0.0-rc3.tar.gz)
• Nextcloud Server Version: 28.0.2

I think that the differences at this point isn't the problem.

Could you provide the list of extensions that is installed at your PHP? You can use this command: php -m

Did you have redis or memcache configured in your setup?

The output of "Configuration settings" at admin page is made with output of this command: occ libresign:configure:check, the difference between the places is a bit strange.

[DazeEnd]

@vitormattos Yes, I'm using Redis. Here's the part of my config.php that relates to Redis:

  'memcache.local' => '\\OC\\Memcache\\Redis',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => 'localhost',
    'port' => 6379,
  ),

PHP modules installed:

[ceperry@newton public_html]$ php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
igbinary
imagick
intl
json
libxml
mbstring
msgpack
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
random
readline
redis
Reflection
session
shmop
SimpleXML
sockets
sodium
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache

If you need any additional information, please let me know. I can also give you an account on the server if that would help. (This is a test server with nothing else on it.)

[vitormattos]

Hi @DazeEnd
Thanks a lot by your contribution.
After a hard work, I think that the problem was fixed.
I will create a new RC with this fix to be more easy to make the tests from your side.

[vitormattos]

I will maintain open waiting by your tests about configuration check.

[DazeEnd]

Hi @vitormattos. Thank you for all your work. I will test your changes tomorrow.

[vitormattos]

https://github.com/LibreSign/libresign/releases/download/v8.0.0-rc4/libresign-v8.0.0-rc4.tar.gz

[DazeEnd]

Hi @vitormattos I installed RC4 and did some testing. Unfortunately, all the problems we discussed yesterday still appear in my tests. Please see my testing log below for details.

Testing: LibreSign v8.0.0-rc4
Date: 2024-02-22
Testing Steps:

1. Uncompress libresign directory from libresign-v8.0.0-rc4.tar.gz and move to Nextcloud apps directory

2. sudo chown -R apache:apache libresign/

3. Enable Libresign app in Nextcloud

4. Install Java, PDFtk, and JSignPdf:

[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --java
Downloading java...
 46080826/46080826 [============================] 100%
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --pdftk
Downloading pdftk...
 31928448/31928448 [============================] 100%
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --jsignpdf
Downloading JSignPdf...
 19027694/19027694 [============================] 100%

5. Refresh Settings > Administration > LibreSign

   Configuration check shows that each line has a status of "error".
   

6. Examine nextcloud.log. The log file is empty.

7. Examine [DocumentRoot]/data/appdata_ocnb4cjpki06/libresign. Everything seems to be there.

[root@newton libresign]# pwd
/var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign
[root@newton libresign]# ls -al
total 49792
drwxr-xr-x.  5 apache apache     4096 Feb 22 09:26 .
drwxr-xr-x. 10 apache apache     4096 Feb 22 09:25 ..
-rw-r--r--.  1 apache apache      115 Feb 22 09:25 checksums_java_17.0.5_8.txt
drwxr-xr-x.  3 apache apache     4096 Feb 22 09:25 java
drwxr-xr-x.  5 apache apache     4096 Feb 22 09:26 jsignpdf-2.2.2
-rw-r--r--.  1 apache apache 19027694 Feb 22 09:26 jsignpdf-2.2.2.zip
drwxr-xr-x.  2 apache apache     4096 Feb 22 09:25 openssl_config
-rwx------.  1 apache apache 31928448 Feb 22 09:26 pdftk

8. Run occ libresign:configure:check from commandline. The commandline reports success.

[ceperry@newton public_html]$ pwd
/var/www/newton-test.relanet.com/nextcloud/public_html
[ceperry@newton public_html]$ sudo -u apache php occ libresign:configure:check
 --------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------- 
  Status    Resource            Message                                                                                                                                  Tip                                         
 --------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------- 
  success   java                Java version: openjdk version "17.0.5" 2022-10-18                                                                                                                                    
  success   java                Java binary: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/java/jdk-17.0.5+8-jre/bin/java                                               
  success   pdftk               PDFtk version: 3.3.3                                                                                                                                                                 
  success   pdftk               PDFtk path: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/pdftk                                                                         
  success   jsignpdf            JSignPdf version: 2.2.2                                                                                                                                                              
  success   jsignpdf            JSignPdf path: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/jsignpdf-2.2.2/JSignPdf.jar                                                
   error    openssl-configure   OpenSSL (root certificate) not configured.                                                                                               Run occ libresign:configure:openssl --help  
 --------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------

9. In LibreSign Administration settings, generate a root certificate. It succeeded.

10. In LibreSign Administration settings, under "Identify factors", change the "Account" signature method to "click to sign".

11. Create a new regular user in Nextcloud.

12. As the admin user, upload a PDF file and request a signature from the regular user created in step 11.

13. In a new Chrome "incognito" window, log in as the regular user created in step 11.

14. As the regular user, begin signing the document sent in step 12.

15. Click the "Define your signature." button, draw a signature, and click the "Save" button.

16. On the "Confirm your signature" dialog, click the "Save" button. The signature was successfully saved.

17. Click the "Sign the document." button, to bring up the confirmation dialog.

18. Click the "Confirm" button on the confirmation dialog. After clicking, an error message appears that reads "Internal error. Contact admin."
    

19. Check nextcloud.log. There are now exactly three lines in nextcloud.log. All three lines include the string "libresign".

[root@newton data]# cat nextcloud.log
{"reqId":"ZddfLGascv3Z@2LdPnEU6wAAAAA","level":3,"time":"2024-02-22T09:50:20-05:00","remoteAddr":"152.117.79.26","user":"charles@relanet.com","app":"PHP","method":"POST","url":"/ocs/v2.php/apps/libresign/api/v1/sign/uuid/8ad5748f-2f99-4a28-8116-c3b480b86f78","message":"Undefined array key \"profileElementId\" at /var/www/newton-test.relanet.com/nextcloud/public_html/apps/libresign/lib/Helper/ValidateHelper.php#306","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36","version":"28.0.2.5","data":{"app":"PHP"}}
{"reqId":"ZddfLGascv3Z@2LdPnEU6wAAAAA","level":3,"time":"2024-02-22T09:50:20-05:00","remoteAddr":"152.117.79.26","user":"charles@relanet.com","app":"libresign","method":"POST","url":"/ocs/v2.php/apps/libresign/api/v1/sign/uuid/8ad5748f-2f99-4a28-8116-c3b480b86f78","message":"OCA\\Libresign\\Service\\SignFileService::forceSaveFileOfDifferentUser(): Argument #2 ($content) must be of type string, bool given, called in /var/www/newton-test.relanet.com/nextcloud/public_html/apps/libresign/lib/Service/SignFileService.php on line 550","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36","version":"28.0.2.5","data":{"app":"libresign"}}
{"reqId":"ZddfLGascv3Z@2LdPnEU6wAAAAA","level":3,"time":"2024-02-22T09:50:20-05:00","remoteAddr":"152.117.79.26","user":"charles@relanet.com","app":"libresign","method":"POST","url":"/ocs/v2.php/apps/libresign/api/v1/sign/uuid/8ad5748f-2f99-4a28-8116-c3b480b86f78","message":"[{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Service\\/SignFileService.php\",\"line\":550,\"function\":\"forceSaveFileOfDifferentUser\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Service\\/SignFileService.php\",\"line\":392,\"function\":\"getPdfToSign\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Service\\/SignFileService.php\",\"line\":281,\"function\":\"getFileToSing\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Controller\\/SignFileController.php\",\"line\":111,\"function\":\"sign\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Controller\\/SignFileController.php\",\"line\":80,\"function\":\"sign\",\"class\":\"OCA\\\\Libresign\\\\Controller\\\\SignFileController\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/lib\\/private\\/AppFramework\\/Http\\/Dispatcher.php\",\"line\":230,\"function\":\"signUsingUuid\",\"class\":\"OCA\\\\Libresign\\\\Controller\\\\SignFileController\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/lib\\/private\\/AppFramework\\/Http\\/Dispatcher.php\",\"line\":137,\"function\":\"executeController\",\"class\":\"OC\\\\AppFramework\\\\Http\\\\Dispatcher\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/lib\\/private\\/AppFramework\\/App.php\",\"line\":184,\"function\":\"dispatch\",\"class\":\"OC\\\\AppFramework\\\\Http\\\\Dispatcher\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/lib\\/private\\/Route\\/Router.php\",\"line\":315,\"function\":\"main\",\"class\":\"OC\\\\AppFramework\\\\App\",\"type\":\"::\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/ocs\\/v1.php\",\"line\":65,\"function\":\"match\",\"class\":\"OC\\\\Route\\\\Router\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/ocs\\/v2.php\",\"line\":23,\"args\":[\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/ocs\\/v1.php\"],\"function\":\"require_once\"}]","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36","version":"28.0.2.5","data":{"app":"libresign"}}

[DazeEnd]

If you need me to do additional testing, or if you would like to schedule a call, please let me know. I am free all day.

[vitormattos]

Hi @DazeEnd did you removed the user libresign from your instance? I tried logging without success

[DazeEnd]

Hi @vitormattos. Sorry about that. I deleted the old Nextcloud installation/database and started over fresh when I installed RC4. I thought that it would make for a cleaner test.

I have recreated your admin account so that you can log in. Just use the same credentials that I sent you before. (I used your "contact" email address as the recovery email address in case you need to reset the password.)

[Aeris1One]

Can still repro the pdftk error using 8.0.0-rc4 released after #2331 was merged.

Did download 3 times, each time deleting the binary pdftk file, in case it was a corrupted download.

EDIT : Server is arch64, downloaded binary is only available for x86_64.

[vitormattos]

Hi @Aeris1One, your case is different, I will move your comment to a new issue and will fix at next release.

[vitormattos]

@DazeEnd looking at your environment just using the web interface, I can't identify what is happening.

Would it be possible to put my ssh public key on your test server? I think it will be easier to identify the problem.
If possible, follow my public key:
https://github.com/vitormattos.keys

[DazeEnd]

@vitormattos I replied to the email you sent from your librecode.coop email address with details about logging in. Please let me know if you have any trouble.

[vitormattos]

I get the access, thanks, making tests now.

[vitormattos]

Hi @DazeEnd
After a lot of tests I get a light over the problem.
When I execute a command using Java from a request by http, your environment don't work, if the request is made by CLI, work fine.
Investigating the problem, I changed the way to execute java because the default way is ignoring errors. When I removed the code to don't display errors or warnings, I got the follow error:

error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

The insight that I got is about the environments of operational system. I need to investigate more and fix the problem.
I think that this is a very specific case but solving this will help a lot the project and other sysadmin to don't get the same problem.

[DazeEnd]

Hi @vitormattos
Thanks for your work on this problem.

Just so I am clear, do I need to install a java package on my server (using dnf) in order to get the libjli.so shared library? Or are you going to make changes to LibreSign that should fix the problem?

[vitormattos]

This .so already exists at java folder that is downloaded by LibreSign. Only at context that the execution of PHP is made by HTTP server, this library isn't loaded.

Install java at your server maybe will solve the problem but is a handmade work. LibreSign have an appsetting to store the path of java. Now, LibreSign download a zip with Java, extract this into appdata/libresign folder and use this java to don't have problems with compatibility.

The objective of "configure check" at administration settings is to remove the necessity to run commands at server side, or, at specific cases, to provide instructions to solve what's necessary. I'm looking if have a way to fix the problem or to give a tip to sysadmin with instructions to solve the problem handmade (maybe installing java at server).

[DazeEnd]

Ok. Since it sounds like you can fix this on your side, I will wait until the next RC and then test that.

[vitormattos]

I tested it with several versions of java and got the same result when trying to run it through a request made to the http server. In all cases, via the command line it works fine.

In all cases with a standalone version of Java (from a compressed file), when running java it returns:

java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

I also tested installing Java on the operating system and in all cases with Java installed on the operating system it returns:

Java8:

OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007faa09000000, 2555904, 1) failed; error='Permission denied' (errno=13)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 2555904 bytes for committing reserved memory.

Java > 8:

Failed to mark memory page as executable - check if grsecurity/PaX is enabled

Looking at Java code I found the follow comment:
https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L4394-L4405

It sounds like it is a block made by your operating system that does not allow the JVM to work.

Could you use another Linux distribution on your server?

On the LibreSign side, what I will do is check that when running Java, the version does not return and if it does not return, I will add a tip to test with another base Linux distribution for the server.

[DazeEnd]

Hi @vitormattos. Your comment above led me to the problem, I think. It appears that the problem is related to SELinux, which runs by default on distributions that are derived from Red Hat (such as the AlmaLinux distribution I use). When I disable SELinux on the server and then start over (deleting and reinstalling Nextcloud and LibreSign v8.0.0-rc4), then install the extra binaries using occ libresign:install --java, occ libresign:install --pdftk', and occ libresign:install --jsignpdf`, then the Configuration check webpage shows "success":

Unfortunately, disabling SELinux in a production server isn't really feasible. SELinux is there for a reason. I want production servers to be security hardened.

I have to end my testing for today, but I suspect that this issues may be related to how the /data/appdata_ocnb4cjpki06/libresign directory was created. Before deleting Nextcloud, I saw that its SELinux context was different. I think that if the directory is created somewhere else (perhaps /tmp), and then copied into place as user apache, it might fix the problems. I will explore this idea more on Monday.

[DazeEnd]

Can you point me to the part of the code that creates the /data/appdata_ocnb4cjpki06/libresign directory? Is that directory moved into place, or is it created (perhaps using PHP's mkdir)?

[vitormattos]

I suspect that this issues may be related to how the /data/appdata_ocnb4cjpki06/libresign directory was created

This directory is created by internal function of Nextcloud:
https://github.com/LibreSign/libresign/blob/main/lib/Service/InstallService.php#L86
and the content of this folder is created by this:
https://github.com/LibreSign/libresign/blob/main/lib/Service/InstallService.php#L93-L112.
Isn't good to create by another way because Nextcloud have a cache of the contents of this folder and files created by another way, don't will be visible to Nextcloud.

In my tests at your server, I created a file inside java/bin folder to check if PHP can execute the file. Worked fine.

I also made the test to change the contnet of file java/bin/java to this simple script:

<?php
echo 'hi';

I made this to check if was something related to content of java file and also worked fine. I also replaced the content of this file by content of other Linux command (the command date) and worked fine too, returning the current date.

Linux have a command called ldd that list the dependencies of a file. With the file java/bin/java at context that PHP is executed from a request of http server, the command ldd don't return nothing, executing the PHP code from CLI work fine.

I identified that your server is using php-fpm and I think that SELinux at your server use anything like a chroot (i don't know if is exactly this) to limit the process to access memory spaces that the JVM need to be executed and because of this the JVM don't work in your environment when is executed from a process started by the php-fpm and work fine when is started directly by php at cli.

[vitormattos]

I think that is necessary to check the policies of SELinux to identify what policy is affecting the execution of JVM.

A very simple way to reproduce the problem and make more tests is:

• Open the index.php at root folderof Nextcloud.
• Replace the begin of index.php by

  <?php
  
  declare(strict_types=1);
  exec('/path/to/bin/java', $output);
  echo implode("\n",$output);
  die();

• Access the url of your server
• See the source code of current page CTRL+U to see the output with line breaks
• Refresh the page that will open every when you change the content of index.php file
• After your tests, return the original content of index.php

This will reproduce the problem.

You can change /path/to/bin/java by any linux command.

Now is necessary identify what policy is blocking the execution of JVM

[vitormattos]

I published a new RC with a small fix that I identified at your environment about the infinity loop when checking the setup status after click at the button.

This RC don't have the fix about SELinux. Will be necessary more tests in your server to identify the policy that is blocking the execution of JVM.

[vitormattos]

I found this that could help:

https://stackoverflow.com/questions/2231735/selinux-prevents-java-from-running

Could you you enable again SELinux to be possible check if this police will solve the problem?

[DazeEnd]

Hi @vitormattos. I just submitted a new issue #2356 that prevents documents from being signed even when SELinux is disabled. I am going to pause my efforts to fix this issue (#2327) until #2356 is resolved. I figure that it doesn't make much sense to try to get things working with SELinux when I can't even get them working without SELinux. Once #2356 is resolved, I will return to this issue.

[vitormattos]

Thanks, I will check the new issue.

[DazeEnd]

Posting here for my future reference: When returning to this issue, test again after running sudo setsebool -P httpd_execmem on.

In the SELinux User's and Administrator's Guide for RHEL 7 I found this entry for the httpd_execmem SELinux boolean:

httpd_execmem

When enabled, this Boolean allows httpd to execute programs that require memory addresses that are both executable and writable. Enabling this Boolean is not recommended from a security standpoint as it reduces protection against buffer overflows, however certain modules and applications (such as Java and Mono applications) require this privilege.

There is no corresponding documentation for RHEL 8, but I have confirmed that the httpd_execmem boolean still exists in RHEL/AlmaLinux 8.

[DazeEnd]

I set the httpd_execmem boolean by running sudo setsebool -P httpd_execmem on, and that seems to have fixed the problem of Apache not being able to run java. But it also seems to have uncovered another problem.

Now the "Configuration check" section is reporting that it cannot find the java shared libraries. I have never tried to get Java to run on an SELinux system, much less allow Apache to run Java on an SELinux system, so it's not clear to me if this is a library path problem when Java is executed by Apache, or if it is anther SELinux access control problem.

I will keep researching.

EDIT: This was not actually the command the cleared the error. (I tried a lot of things during testing, and attributed the "fix" to the wrong command. See my update below.

[vitormattos]

Hi @DazeEnd
I identified a problem at this java version that in specific scenario (I lost the scenario, I only fixed the problem) got problems to run Java.
I already made a bump at Java version of LibreSign and solved the problem that I identified.
I can create a new release to be more easy to you to install but I'm waiting to make more small fixes before launch the release. If you prefer to test now without making the build of project, I can launch a new release.

Still in time, to build handmade before launch the new release, is necessary follow these steps:

• clone libresign repository replacing the libresign folder at app folders
• run composer install --no-dev (need composer)
• Run npm ci;npm run build, is necessary NPM

[vitormattos]

I never made a setup using SELinux. This also is new to me.
At my setups I use Docker to run Nextcloud.

[DazeEnd]

Hi @vitormattos. I will probably stop testing until you release a new RC. I need to reinstall the server and verify that it was actually the sudo setsebool -P httpd_execmem on that allowed Java to run. (I was making a lot of changes, and it may have been something else that I did.) Once you release a new RC, I will test to see if the "shared library" errors go away.

Thanks for all your help on this problem.

[vitormattos]

I think that after we identify what happening and the solution, that would be good to identify if the environment have SELinux and present to sysadmin the solution of problem.

[DazeEnd]

I was wrong in my comment above. the sudo setsebool -P httpd_execmem on command was NOT the command that allowed apache to finally run java. These are the steps that actually allowed java to run:

1. Install the setroubleshoot package: sudo dnf install setroubleshoot-server

2. In Nextcloud, refresh Settings > Administration > LibreSign to refresh the "Configuration check" section. This will cause java to log another SELinux message.

3. Use sealert to analyze the error, and suggest a new SELinux policy. In my case it suggested I run:

sudo su -
cd
ausearch -c 'java' --raw | audit2allow -M my-java
semodule -X 300 -i my-java.pp

After executing the commands in step 3, java ran successfully and I was left with the shared library error.

Note: The audit2allow command generates two files that are used to update the SELinux policy: a binary file and a text file. The generated text file contained the following:

module my-java 1.0;

require {
        type httpd_sys_rw_content_t;
        type httpd_sys_script_t;
        class file execute;
}

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t httpd_sys_rw_content_t:file execute;

[vitormattos]

Wow! Excellent!
Sounds that now all related with Java will work fine!
In the next release will come with the latest Java version.
I'm only finishing small fixes before launch the next release. I think that today in the end of my work I will to this.

[DazeEnd]

Maybe, but I'm not sure yet. I still have the "shared library" error:

I am hopeful that the changes you made to Java will fix this issue, but I have my doubts. LibreSign worked correctly when SELinux was completely disabled, so I suspect that there is still some SELinux errors at work here.

I am continuing to investigate.

[DazeEnd]

@vitormattos Ok. I think I have it. There are three different SELinux policies/permissions that had to be changed:

• execute: This is required for java to run
• execmem: Apache (httpd) needs this permission to run java
• noatsecure: This is required so that java can find its shared libraries

After making the necessary SELinux policy changes, I got the "Configuration check" section to work correctly:

Here are the complete steps that I followed on my AlmaLinux 8 (RHEL 8) server to make the necessary SELinux policy changes:

1. Install "setroubleshoot-server": sudo dnf install setroubleshoot-server

2. Give Java execute SELinux execute permission:

   a. In Nextcloud, refresh Settings > Administration > LibreSign to refresh the "Configuration check" section.

   b. Run sealert -l "*" to generate SELinux policy suggestion

   c. Create SELinux policy suggested in Step 2b.

sudo su -
cd
ausearch -c 'java' --raw | audit2allow -M my-java-execute
semodule -X 300 -i my-java-execute.pp

3. Give Apache execmem permission: sudo setsebool -P httpd_execmem on

4. Give java noatsecure permissions so that java can find shared libraries.

   a. Log all SELinux messages, including "dontaudit" messages: sudo semodule -DB

   b. In Nextcloud, refresh Settings > Administration > LibreSign to refresh the "Configuration check" section.

   c. Run sealert -l "*" to generate SELinux policy suggestion. Search the output for "java". You should see that SELinux is preventing java from using "noatsecure" access. (This is preventing java from finding the required shared libraries.)

   d. Create the SELinux policy suggested in Step 4c:

sudo su -
cd
ausearch -c 'java' --raw | audit2allow -M my-java-noatsecure
semodule -X 300 -i my-java-noatsecure.pp

5. Suppress logging of "dontaudit" SELinux messages: sudo semodule -B

I have not yet tested whether I can actually sign documents with this configuration. I've run out of time today, so I will try to find time tomorrow to test the signing process.

[vitormattos]

@DazeEnd could you test again with the new release?

[DazeEnd]

@vitormattos Yes, I will. But it might have to wait until Monday. Today is the first of the month, and I have some other administrative/bookkeeping work that will be taking up most of my day.

[DazeEnd]

For the benefit of anyone who tries to set this up in the future, I have identified a fourth SELinux change that is required for RHEL/AlmaLinux 8. I needed to give Apache the SELinux tmp_exec permission in order to be able to actually sign a document. This permission can be granted by turning on an SELinux boolean using this command: sudo setsebool -P httpd_tmp_exec on

[vitormattos]

I will maintain this issue open to check how we can identify if is a problem at SELinux side.

[daniromome]

I have this same issue whenever I try to sign a document, using arch linux.

{"reqId":"LDYy91OmpQgD9UE2E7KH","level":3,"time":"2024-05-22T02:20:20+00:00","remoteAddr":"REDACTED","user":"REDACTED","app":"libresign","method":"POST","url":"/ocs/v2.php/apps/libresign/api/v1/sign/uuid/85217564-26a7-49e7-a516-e0d21bfa715f","message":"OCA\\Libresign\\Service\\SignFileService::forceSaveFileOfDifferentUser(): Argument #2 ($content) must be of type string, bool given, called in /var/lib/nextcloud/apps/libresign/lib/Service/SignFileService.php on line 584","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0","version":"29.0.0.19","data":{"app":"libresign"}}
{"reqId":"LDYy91OmpQgD9UE2E7KH","level":3,"time":"2024-05-22T02:20:20+00:00","remoteAddr":"REDACTED","user":"REDACTED","app":"libresign","method":"POST","url":"/ocs/v2.php/apps/libresign/api/v1/sign/uuid/85217564-26a7-49e7-a516-e0d21bfa715f","message":"[{\"file\":\"\\/var\\/lib\\/nextcloud\\/apps\\/libresign\\/lib\\/Service\\/SignFileService.php\",\"line\":584,\"function\":\"forceSaveFileOfDifferentUser\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/lib\\/nextcloud\\/apps\\/libresign\\/lib\\/Service\\/SignFileService.php\",\"line\":417,\"function\":\"getPdfToSign\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/lib\\/nextcloud\\/apps\\/libresign\\/lib\\/Service\\/SignFileService.php\",\"line\":276,\"function\":\"getFileToSing\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/lib\\/nextcloud\\/apps\\/libresign\\/lib\\/Controller\\/SignFileController.php\",\"line\":110,\"function\":\"sign\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/lib\\/nextcloud\\/apps\\/libresign\\/lib\\/Controller\\/SignFileController.php\",\"line\":79,\"function\":\"sign\",\"class\":\"OCA\\\\Libresign\\\\Controller\\\\SignFileController\",\"type\":\"->\"},{\"file\":\"\\/usr\\/share\\/webapps\\/nextcloud\\/lib\\/private\\/AppFramework\\/Http\\/Dispatcher.php\",\"line\":232,\"function\":\"signUsingUuid\",\"class\":\"OCA\\\\Libresign\\\\Controller\\\\SignFileController\",\"type\":\"->\"},{\"file\":\"\\/usr\\/share\\/webapps\\/nextcloud\\/lib\\/private\\/AppFramework\\/Http\\/Dispatcher.php\",\"line\":138,\"function\":\"executeController\",\"class\":\"OC\\\\AppFramework\\\\Http\\\\Dispatcher\",\"type\":\"->\"},{\"file\":\"\\/usr\\/share\\/webapps\\/nextcloud\\/lib\\/private\\/AppFramework\\/App.php\",\"line\":184,\"function\":\"dispatch\",\"class\":\"OC\\\\AppFramework\\\\Http\\\\Dispatcher\",\"type\":\"->\"},{\"file\":\"\\/usr\\/share\\/webapps\\/nextcloud\\/lib\\/private\\/Route\\/Router.php\",\"line\":338,\"function\":\"main\",\"class\":\"OC\\\\AppFramework\\\\App\",\"type\":\"::\"},{\"file\":\"\\/usr\\/share\\/webapps\\/nextcloud\\/ocs\\/v1.php\",\"line\":66,\"function\":\"match\",\"class\":\"OC\\\\Route\\\\Router\",\"type\":\"->\"},{\"file\":\"\\/usr\\/share\\/webapps\\/nextcloud\\/ocs\\/v2.php\",\"line\":23,\"args\":[\"\\/usr\\/share\\/webapps\\/nextcloud\\/ocs\\/v1.php\"],\"function\":\"require_once\"}]","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0","version":"29.0.0.19","data":{"app":"libresign"}}

and I also have the issue where the pdftk binary is not detected on the config check

[vitormattos]

Hi @daniromome I think that your case isn't the same because the Java is working fine. Could you move to a new issue to we have a best interaction in a specific thread?