Nginx on David Hamann

How to get rid of web server upgrade prompts when installing FileMaker Server on Ubuntu Linux

Mon, 05 Jan 2026 00:00:00 +0000

A while back the FileMaker Server (FMS) installer for Ubuntu Linux started checking the currently installed web server versions and giving warnings and an interactive prompt (!) in case of outdated versions.

This is rather annoying if you like to install/upgrade your FMS non-interactively. Using ansible, for example, your playbook would just hang and you would start wondering what’s going on.

Let’s see what is actually happening, why it’s happening, and how to solve it.

What is happening?

When you follow the official documentation on “silent installations”, you could assume that setting up a complete Assisted Install.txt file and using the following command is all that is necessary:

sudo FM_ASSISTED_INSTALL=path apt install package_path/filemaker-server-version.build-architecture.deb

In the current and previous version (22.0.2 and 22.0.4) you will, however, eventually see something like this on stdout in the installation process:

Warning: Current nginx version($nginxVersion) is too low, it probably can lead a serious security issue! Please run the script -- NginxUpdate.sh to upgrade it to the latest version!(Ignore: If use Apache)
Do you want to continue to install? [y/n]

Non-interactively, you obviously won’t see anything and thus won’t be able to answer the prompt.

More annoyingly, canceling the installer in this state will likely break the whole installation leading to dpkg telling you that filemaker-server has to be re-installed.

Why is it happening?

Let’s take a quick look at the debian package to understand why this is happening:

# unzip the installer
unzip fms_22.0.4.427_Ubuntu24_amd64.zip

# extract the archive
ar x filemaker-server-22.0.4.427-amd64.deb

# extract the tarball
tar xf control.tar.zst

Now that we have access to the control scripts we can have a look at the bash script preinst.

In it, we see the function checkNginxAndApacheVersion():

checkNginxAndApacheVersion()
{
 :
 local result=$ERROR_NONE

 nginxVersion=$(nginx -v 2>&1 | grep -oP 'nginx/\K[^ ]+')
 apacheVersion=$(apache2 -v 2>&1 | grep -oP 'Apache/\K[^ ]+')

 if dpkg --compare-versions $nginxVersion lt 1.27.0 || dpkg --compare-versions $apacheVersion lt 2.4.57; then

 dpkg --compare-versions $nginxVersion lt 1.27.0 && message "Warning: Current nginx version($nginxVersion) is too low, it probably can lead a serious security issue! Please run the script -- NginxUpdate.sh to upgrade it to the latest vers
ion!(Ignore: If use Apache)"

 dpkg --compare-versions $apacheVersion lt 2.4.57 && message "Warning: Current apache version($apacheVersion) is too low, it probably can lead a serious security issue! Please run the script -- ApacheUpdate.sh to upgrade it to the latest
version!(Ignore: If use Nginx)"

 read -r -p " Do you want to continue to install? [y/n]"
 if [[ "$REPLY" = "y" || "$REPLY" = "Y" || "$REPLY" = "yes" || "$REPLY" = "YES" ]]; then
 result=$ERROR_NONE
 else
 result=$ERROR_INTERRUPT
 fi
 fi

 :
 return $result
}

You can see that both nginx and Apache versions are checked against hardcoded version numbers, and if either one is lower than the target version a prompt will appear, trying to read from stdin (read -r -p "...").

I don’t know why they are checking for both versions and not depending on what web server is or will actually be in use.

If we trace the calls to the function, we see a little further up that the check only takes place under certain conditions:

isLicenseAccepted()
{
 ...
		if [[ $result -eq $ERROR_NONE && $SECURITY_CHECK = true ]]; then

So where is $SECURITY_CHECK coming from?

It’s actually read from the Assisted Install.txt file in readAssistedInstallInfo():

if [[ $fileValid = true ]]; then
 key=$(echo "$line" | cut -d "=" -f 1 | xargs)
 value=$(echo "$line" | cut -d "=" -f 2)

 case "$key" in
 "Security Check" )
 case "$value" in
 "1" | "true" | "True" | "yes" | "Yes" )
 SECURITY_CHECK=true
 ;;
 * )
 SECURITY_CHECK=false
 ;;
 esac
 ;;

Essentially, this means we can jump over this interactive prompt by setting Security Check=0 in our Assisted Install.txt.

Looking at the documentation of assisted installs, there’s unfortunately no mention of this flag: Assisted install of Claris FileMaker Server (at the time of this writing).

Once I found the flag name, I researched a bit more and eventually found that it’s actually officially documented – just somewhere else (oh, well). Look at “Linux: Show the Apache and Nginx update warnings” here: Customize the personalization file.

The solution

After this little detour into the installer, the solution is quite simple:

Set Security Check=0 if you don’t want to be prompted.

Alternatively, make sure to upgrade your web server versions (unfortunately both nginx and Apache) to the indicated version first, and then run your non-interactive install.

You can find the upgrade scripts in the package as well; they are called: NginxUpdate.sh and ApacheUpdate.sh.

I hope this saves someone else a little bit of digging :-)

nginx alias misconfiguration allowing path traversal

Sun, 14 Aug 2022 00:00:00 +0000

I recently came across an nginx server that had a vulnerable alias configuration which allowed anyone to read files outside the intended directory. In the following post I will describe the misconfiguration and provide demo files so that you can experiment with it yourself.

The general issue was originally highlighted a few years ago in a BlackHat presentation (Breaking Parser Logic!, Orange Tsai) and apparantly first shown even earlier. While the linked presentation only has a couple of slides on this particular issue it’s worth checking out in full.

The docker setup

Let’s say we have a PHP application that should be served through nginx. To quickly get things running we configure our setup via the following docker-compose.yml file:

version: "3.7"

services:
 web:
 image: nginx:alpine
 ports:
 - 8081:80
 networks:
 - internal
 volumes:
 - ./webapp:/var/www/webapp
 - ./nginx.conf:/etc/nginx/conf.d/default.conf
 depends_on:
 - php

 php:
 image: php:fpm-alpine
 volumes:
 - ./webapp:/var/www/webapp
 networks:
 - internal

networks:
 internal:
 driver: bridge

We have two services, web (nginx) and php, mount our php source code and nginx.conf and have the services on the same internal network.

Our directory structure will look like this:

.
├── docker-compose.yml
├── nginx.conf
└── webapp
 ├── app
 │   ├── db.php
 │   └── webroot
 │   └── index.php
 └── static
 └── sample.png

The nginx config

Our nginx.conf file will be a fairly simple and standard-looking one which already has the issue baked in (can you see it?):

server {
 server_name _;

 root /var/www/webapp/app/webroot;
 index index.php index.html index.htm;

 access_log /var/log/nginx/php-access.log;
 error_log /var/log/nginx/php-error.log;

 location /assets {
 alias /var/www/webapp/static/;
 }

 location / {
 try_files $uri $uri/ /index.php?$query_string;
 location ~ \.php$ {
 include fastcgi_params;
 fastcgi_pass php:9000;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 }
 }
}

The web app

Our demo web app is really just for demonstration purposes and doesn’t do anything useful.

We have webapp/app/db.php (to have a file outside of the webroot that contains some credentials):

<?php

$user = 'appuser';
$pass = 'secret';
$db = new PDO('mysql:host=localhost;dbname=test', $user, $pass);

// ...

?>

And then our index.php in the webroot folder to show an intended output of the PHP application:

<?php

echo 'Here is the webroot';

?>

Launch the application and see the issue

Now that we have all necessary demo files set up, we can launch our containers:

docker-compose up --build

Going to http://127.0.0.1:8081 should now return Here is the webroot, which is the output of index.php in the webroot folder.

As seen in the above nginx config we also have an /assets location pointing to the /static directory. Navigating to http://127.0.0.1:8081/assets/sample.png gives us the sample image, as expected.

So what’s the issue?

The /assets location directive has no trailing slash and nginx will thus only match /assets and then append whatever is in the request to the final destination path.

If we open http://127.0.0.1:8081/assets../app/db.php we can force a directory traversal and access files in a directory one level down. For our demo app this means we can access the source code of db.php, a sensitive file outside of the webroot. Here, /assets../app/db.php effectively becomes /var/www/webapp/static/../app/db.php.

Note that attempts to force “regular” directory traversals in a requested path, as in /../, are obviously prevented by default.

While we could of course prevent the PHP source code from being returned vs. evaluated, this would not change the fact that we could still access other files one directory down – for example something like /assets../app/.env.

The fix here is to make sure to always set the full path in the location directive, as in location /assets/ (note the trailing slash).

The files

You can access the demo files via this GitHub gist.