Pluggable WebDAV Server

This type of post is not a manual or an in-depth explanation of the project. It’s more like a general overview of the functions provided by it and how it can be extended. But first, let me explain the situation.


At work, we use NFS shares secured by Kerberos on our machines to provide the users with there home folders and group folders. With devices that we control this scheme works great and is pretty performant for our needs. But with the basic principle of “bring your own device” it starts to crumble. We know that there are many protocols out there that could achieve what we wanted. But most of them lack security or are not available on all platforms. The former one is especially true for FTP.

While FTP is kind of supported in all modern operating systems it’s secure form FTPS (FTP over TLS) is not. Another protocol that would suit well was SFTP (ssh based file transfer protocol). We canceled that idea because it was not well supported on most OSs.

SMB/CIFS was lacking security features when used over the internet (At least in the most supported protocol versions). It would have an advantage over the other ones: Integrated Kerberos authentication. Because of our security concerns we also did not choose that approach.

Then WebDAV came to our rescue. It allowed us to share folders across our network and across the internet in a well tested and secure manner. Behind the scenes, it uses HTTPS to transfer requests, files, and credentials over a not secure path. It is also supported on all major operating systems (Windows, Mac OS X, Linux, Android, and iOS). We started to search for server applications that could fulfill our needs. Most of them worked great protocol-wise and the authentication was either directly coupled to Kerberos or worked by utilizing pam (local system-auth), but per user flexibility on which folders to export was mostly not given. WebDAV was designed around the idea that you would export only one directory to a large number of users. In our example, we wanted a different folder for every user to export. User A should become /home/user-a exported and User B should become /home/user-b.

This requirement was fulfilled by a small project which implemented a chroot on authentication. That solution would have worked if we didn’t have other shares that we needed to access as well. There was, for example, the /group folder. We could have placed a link inside every user home directory to /group but chrooting to that home directory would prevent access to /group. Also manipulating users home directory is not good practice so we tried to prevent that.

Orbit WebDAVd

We finally decided to build our own WebDAV server to provide our and probably other needs. It can be extended to not only access filesystems but also other types of structured information. It does so by aggregating virtual filesystems that handle common file operations.

Virtual Filesystems

When mounting an Orbit-WebDAV root directory you are not accessing a real filesystem directly. Instead, you will see virtual filesystems that can be mapped to different locations. For our example, we would like every user to become their own home directory and the group directory exported. There are two virtual filesystems integrated that could do that: DirectoryFilesystem (exports exactly one real filesystem) and HomeFilesystem (like DirectoryFilesystem but is directly coupled to the authenticated users home directory). One could now set up our Orbit-WebDAVd root as follows:

  • /home -> HomeFilesystem
  • /group -> DirectoryFilesystem(“/group”)

When mounting the Orbit-WebDAVd server inside an operating system the user would see /home and /group. He can then navigate inside one of these to access the proper files/directories.

By implementing VirtualFilesystem one could also export key-value storage like Redis in the same manner. If you find a good way to wrap around the file/directory scheme you could also add a VirtualFilesystem that accesses a MySQL Server. The possibilities are nearly endless.

Authentication Provider

The server can have exactly one Authentication Provider the authentication providers defines a way how users can authenticate to the server.

  • DebugAuthenticator – Successfully authenticates users when their username equals their password
  • StaticAuthenticator – Successfully authenticates users when their username and password matches an entry inside a static list provided to the authenticator
  • PAMAuthenticator – Successfully authenticates users when their username and password successfully authenticatees at a local PAM service


There are currently a few bugs around. File saving inside Mac OS X is not successful in some programs while it works with others. If you would like to help this project come further, don’t hesitate to make pull requests on the project git: