Csdrhrt

I've written a webpage that lets me remotely mount an encfs encrypted folder, which is then accessible via WebDAV. It's basically just a password form with a mount / unmount button, which tries to mount / unmount a predefined encfs encrypted drive with the password supplied via the form. Basically a internet accessible wrapper to

encfs --stdinpass /encfs/drive/encrypted/ /var/www/unencrypted

This works as intended, as in I can mount / unmount the encrypted drive and I can see / read the unencrypted data via WebDAV.

But there is something strange going on:
The unencrypted view of the folder is ONLY accessible via WebDAV.

If I run sudo -u www-data ls -la /var/www (www-data is the user running the webserver and therefore also the user mounting the drive, I've confirmed this with htop) or as any other user, I see the mounting point (in the example above this would be /var/www/unencrypted) as a regular folder, not like a typical encfs folder, which should normally look something like this:

drwxr-xr-x  5 www-data www-data  4096 Feb  1 02:25 .

drwxr-xr-x 15 root     root      4096 Jan 31 11:46 ..

d?????????  ? ?        ?            ?            ? unencrypted

but actually it looks like that:

drwxr-xr-x  5 www-data www-data  4096 Feb  1 02:25 .

drwxr-xr-x 15 root     root      4096 Jan 31 11:46 ..

drwxr-xr-x  2 www-data www-data  4096 Jan 31 21:47 unencrypted

just like a normal folder (which is reported as being empty, although the same folder has data in it when accessing it via WebDAV).

Also there is no entry in /etc/mtab indicating that the encfs drive was ever mounted. For all intents and purposes, it looks as if the drive was never mounted, although it in fact definitely is, because I can access it via WebDAV and also the ecnfs process is clearly running, as shown in htop.

How does this happen and how to fix this?

PS: If I run

sudo -u www-data bash -c "echo $(cat /tmp/passwort_file) | encfs --stdinpass /encfs/drive/encrypted/ /var/www/unencrypted"

from the terminal, there is no such behavior. The folder is still accessible via WebDAV, but in this case it also correctly appears in /etc/mtab and is also visible as an encfs drive when using ls -la.

I'm assuming this is Debian Linux or Ubuntu, with systemd as the service manager.

Linux supports "mount namespaces" which provide different views of the filesystem to different processes (like chroot but much more flexible and headache-inducing). Systemd allows using this feature to harden the system against security issues and attacks; for example, certain services may see /home as empty or /etc as read-only.

Most distributions use these security settings in apache2.service – if you run systemctl cat apache2, you'll see that it's configured to have its own private /tmp directory:

[Service]

...

PrivateTmp=true

The side effect of mount namespaces is that they're somewhat global: once systemd "unshares" / to be able to create Apache-only mounts underneath, even if it only needs a single mount, the same effect still applies to all mounts created by the Apache service. (For services, this is to some extent intentional: why would a web server need to mount filesystems, really? Principle of least privilege.)

So if you run findmnt or cat /proc/self/mounts, you will only see mounts in the root namespace. But if you run nsenter --mount --target <APACHE_PID> findmnt or cat /proc/<APACHE_PID>/mounts, you'll see both those inherited from root namespace, and those private to the Apache process.

To disable this protection, run systemctl edit --full apache2 and remove all settings starting with Private*, ReadOnly*, or Inaccessible*.