2

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.

2
  • I dont think your test command runs the mount as www-data (only the echo)
    – davidgo
    Feb 1, 2019 at 9:23
  • You are right, sudo - u www-data would only apply to the echo, not everything after the pipe. But actually I run the whole command in a script, so it should run everything as www-data (and looking at htop it does). Sorry for the confusion, I will change the test command example to reflect that.
    – luksen
    Feb 1, 2019 at 12:31

1 Answer 1

1

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*.

3
  • Thank you, I can confirm that this was exactly the issue. I kinda suspected that apache2 might run in some kind of "protected environment", but I didn't know that this "mount namespaces" even existed. Glad I learned something new. Now I am reluctant to completely disable this protection. Is there any way to only disable it for this one command/mounting point?
    – luksen
    Feb 1, 2019 at 21:10
  • After reading into nsenter, I found out that I can use it to enter the namespace of the root PID, if I use nsenter --all --target 1 encfs [...]. With this, the mounting / unmounting works globally, but I guess it's pretty unsafe to nsenter the namespace(s) of the root PID?
    – luksen
    Feb 2, 2019 at 0:14
  • Well, the problem is that you need root privileges to do this in the first place... It's doable (using sudo), but you should be very precise when writing the sudo rules – only allow the exact command that's needed, without variations or wildcards. Feb 2, 2019 at 0:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .