WebDAV: File Transfers as Easy As Your Desktop

The latest hot protocol for all you cutting-edge admins is WebDAV, or “Web-based Distributed Authoring and Versioning.” WebDAV converts HTTP/HTTPS from a read-only protocol into a read/write protocol. Or, in plainer terms, it makes Web publishing almost as easy as Web surfing. Because the DAV protocol is an extension to HTTP, it can take advantage of existing features like SSL for encryption and certificate-based authentication, and HTTP basic authentication. And a nice side benefit is gliding through firewalls with ease.

Of course WebDAV has been adapted for more than just authoring Web sites. It’s a nice cross-platform file sharing tool, an alternative to FTP and Samba that is simpler to use on the client side. Windows and Macintosh have native WebDAV support; Linux support requires either the davfs kernel module, the standalone Cadaver client, or Konqueror, the amazing KDE browser that supports boatloads of protocols.

Windows users can easily access WebDAV shares from Network Neighborhood or Internet Explorer. MacOS users need the free Goliath client. OS X comes with WebDAV support built-in. So getting clients connected is the easy part. Access controls are the tricky part of using WebDAV. Most times you want to limit users to certain directories, and keep them far far away from your httpd.conf file, and often from each other.

Running a WebDAV server is as easy as bolting the appropriate bits onto Apache.

Adding WebDAV To Apache

WebDAV is an easy add-on to an Apache server, either 1.3 or 2.0. If mod_dav is not enabled on your 1.3 Apache, add it as a loadable module. You’ll need your Apache source tree. First download mod_dav-1.0.3-1.3.6 to your source tree, then:

# ./configure --with- apxs=/usr/local/apache/bin/apxs
# make
# make install

As every Linux distribution likes to play silly games with Apache file locations, you’re on your own for verifying where your /bin/apxs file resides.

Apache 2.0 is easy as pie if you enabled the with-dav option when you first compiled it, to build in WebDAV support; and if you were also foresightful enough to compile with the –enable-so option, which lets you add any loadable module you want after compilation without rebuilding the binary. Like the mod_dav_fs module, which is needed to make WebDAV work:

# ./configure --prefix=/usr/lib/apache2/modules --enable-dav-fs

Then add these lines to httpd.conf, or apache2.conf, or whatever you have:

LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
LoadModule dav_fs_module /usr/lib/apache2/modules/mod_dav_fs.so

Again, check your own file locations.

Configuring Apache

We’re not done with httpd.conf yet. The next step is to define your lock database:

<IfModule mod_dav.c>
       DAVLockDB /var/lock/apache2/davlock

Make sure the “davlock” directory exists, and is owned by the server owner and group, which are defined in httpd.conf:

User www-data
Group www-data

Never use the “nobody” user. Apache should have its own unique user and group.

If Windows users are going to access your DAV shares, make sure this line exists and is uncommented to compensate for buggy behaviors:

BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully

Create a directory to hold your DAV files, then turn on DAV on this directory with this httpd.conf directive:

<Directory "/var/www/apache2/davfiles">
      DAV On

All subdirectories and files in this directory are DAV-enabled. Restart Apache and give it a simple test. For example in Konqueror, try connecting locally with http://localhost/davfiles. You should see a nice empty directory. Try copying in a file from your local file tree. Or use Cadaver, like this:

$ cadaver
$ dav:!> open http://localhost/davfiles
$ Looking up hostname... Connecting to server... connected.
$ dav:/davfiles/> put randomfile.txt
$ Uploading randomfile.txt to '/davfiles/randomfile.txt':
$ Progress: [= == == == == == == == ==>] 100.0% of 168 bytes succeeded.

It works! Now let’s set it up for other users.


This is the tricky bit. You don’t want to leave your nice WebDAV server wide open to any old hax0r. First, make sure your authentication database and .htaccess files are not owned by the server user. They should be owned and writable only by the root user. Next, set up per-directory access permissions. This uses Apache’s built-in “Digest” authentication, which scrambles the logins with an MD5 hash. This is pretty lightweight security, don’t use it for commercial transactions or super-secret documents. Which do not belong on a Web server anyway. It is plenty good enough to foil casual snoopers.

<Directory "/var/www/apache2/davfiles">
      AuthType Digest
      AuthName "dav files"
      AuthUserFile /etc/apache2/.htpasswd-davfile
      Require valid-user

Next, create the password file:

# htpasswd -c etc/apache2/.htpasswd-davfile user1

Add additional users like this:

# htpasswd etc/apache2/.htpasswd-davfile user2

Don’t forget to record the passwords and give them to your users.

For an extra layer of security, run a dedicated WebDAV server owned by a unique user. Don’t use it for anything else, and don’t let the server user own any other services. You can run two Apache servers on the same box with the same IP if you give them different ports. For example, your public Web server should be on the default port 80, and your DAV server could be 8080. Users connect with a URL like http://davserver.net:8080. This solves the problem of DAV violating a basic Apache security feature: the web server user (in this article, www-data) must not be able to write to any files. However, DAV simply will not work if the server user cannot write to files.

You can set up as many DAV-enabled directories for as many users as you care to bother with. Unlike Samba or NFS, WebDAV shares are as easy to access across the Internet as they are on the LAN. WebDAV supports HTTPS for encrypted authentication and transport; see Resources for a link to a comprehensive howto.


Latest Articles

Follow Us On Social Media

Explore More