Implementing True WebDAV Homedirs? 47
"Apache has mod_dav, which seems to be primarily designed to provide a single shared space to files, where the Apache process user has read/write access. mod_auth_digest doesn't seem to be usable at the same time as mod_auth_shadow. It would appear that the only way to 'properly' do what I want to do would be to run Apache as root(!), have vhosts for every user (webdav.username.domain.com), have Apache change to that user's uid and gid before enabling webdav for their home directory, and then use basic authentication instead of digest authentication.
Is anyone out there trying this? Has Anyone used Jigsaw, kirra-httpd or even the no-longer-available MoulDAVia in a production environment? What are you using to provide non-trivial, safe WebDAV services?
I know I can use something like a restricted SCP- and SFTP-only shell, like scponly and rssh, but again, I'd prefer WebDAV as it wouldn't require the end user to install a client
application."
mod_become (Score:5, Interesting)
You've pretty much hit the nail on the head when it comes to correct file permissions and remote access to folders under apache.
The only way to really achieve it is to allow apache to set(e)uid to the user who you want it to be running as. I extended mod_become [snert.com] for our internal use here, and it works ok, but yes, you need to run apache as root to achieve this. I wouldn't want to go exposing it to the world-at-large.
mod_waklog (Score:4, Informative)
Re:mod_become (Score:3)
a remote exploit can allow a cracker to write on
as root. To solve:
You could make the module run as a daemon uid, and
have it invoke a setuid program that sets uid to the
final user's.
Re:mod_become (Score:2)
Re:mod_become (Score:2)
Wrong. Any root process can break out of a chroot jail. chroot only protects non-root processes.
A name from the distant past... (Score:2, Interesting)
Have you looked at any of the tools from Novell? They've invested a fair amount of effort in WebDav [novell.com], they've transitioned to Apache, and NetWare 7 promises to run on a Linux kernel.
Plus, they're the only shop in the bidness with a robust, distributable, replicatable, dynamically inheritable directory service [without which they would've long since ceased to exist].
ryo (Score:2)
won't work? (Score:2, Interesting)
It's kind of a nasty hack, but won't this work?
??Re:won't work? (Score:1)
You need some way to make apache spawn a fork as the user in question so that you limit access to that available to that user.
Phew, that was terse
yes it will! (Score:1)
set up a webdav folder and give each user their own dir
chown it www chgrp webdavusers
ln -s
And viola, roberts your fathers brother
Re:yes it will! (Score:2)
just so long as none of your users actually want to write to their files or folders.
WebDAV needs the permissions on files to be at least 660 to www:www, and at least 770 to www:www (assuming you want your users to actually be able to do something other than read files from the server.
Re:yes it will! (Score:1)
If it was 660, how would the webserver get access? Eitherway, make users part of www group
Re:yes it will! (Score:1)
Re:yes it will! (Score:1)
:)
The other thing I would recommend is adding the sticky bit to group, so that files and folder will be forced to pick up the group permissions (retain them, actually) when created.
I played around with this last year in 1.3 and 2.0 versions and I thought it was reasonably sound, aside from that limitation. And hey, if they don't want other people prying around it, then you'd better no be putting it on a webserver to start with. Duh.
Will the chimay dude (below) sen
Re:yes it will! (Score:2)
<Location
<Limit PUT POST DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
require user harvey.wallbanger
</Limit>
</Location>
If you don't want other users to see the stuff in that guy's folder toss GET and HEAD in the Limit directive.
Re:yes it will! (Score:2)
Sorry. Too much Chimay last night.
I seem to have missed the part about chowning and chgrouping.
Ah well.
Re:yes it will! (Score:1)
Have the user own the files but use ACLs to give the apache user access to read/write/create the files.
Re:yes it will! (Score:1)
But this does nothing to limit permissions between each user's "dav home". The question raised is whether you can add restricions so that each user can read/write files as their user on the server, not as www, or root, or whoever is running httpd.
I think it's clear that there needs to be a organized, well-though-out migration away from Unix file meta-data users and groups towards more versatile ACLs. Hopefully in a way that will make it easy for software such as Apache to use these new ACLs for control
Authentication vs. Authorization (Score:1)
You're mixing authentication (identity) with authorization (privilege). Read up on Apache::Authen vs Apache::Authz . You can intercede arbitrary access control modules (via the C or Perl APIs), before any content handling module (incl. DAV).
Brown has documented an elaborate system [brown.edu].
Re:won't work? (Score:3, Interesting)
I mean, I can see this actually working if you do something like rsync between two servers or sync two directories, one preserving file ownerships a la the UNIX security paradigm, one owned by webserver, using WebDAV security.
The shortcoming here is that you couldn't use groups very easily, but you could work around this without too much difficulty.
WebDAV was never meant to mirror the UNIX user/group paradigm. I think as close as you can get is the Apple
Re:won't work? (Score:1)
It's too bad that HTTP/dav is so limiting, because it is a pretty useful tool. Well supported and fairly cross-platform. Not to mention Adobe's integration into Photoshop and Illustrator (or Macromedia's integration into Dreamweaver and Fireworks).
SSH? (Score:1)
Re:SSH? (Score:1)
You read the part about the preferability of no extra client software to install, right? Last I checked, PuTTY on Windows was a separate download. SSL is built into Windows.
Some of my experiences (Score:4, Informative)
Somethings to watch for: Windows 2000 SP2 had some issues with the mod_dav/mod_ssl combination we're running (uploads failed). Upgrading to SP3 fixed that problem.
Windows makes it a royal pain in the ass if you are planning on using self-signed certificates. I just couldn't figure out how to make IE accept self-signed CA certs. After literally years of seeking this information, I've finally found a solution this past week. This is something you have to consider for your users if you're going to use SSL with self-signed certs: how much can they take the constant popup cert warnings and how happy will they be about going through a 8 step process to get rid of it. Either way: poor user experience, which makes it hard for me to convince my users that DAV is a good thing (they're used to FTP).
OSX natively supports DAV but unless something has changed recently, it does NOT natively support DAV over SSL. You need Goliath [webdav.org] for that. At least Goliath has a single "Accept this certificate permanently?" button that actually does what it advertises
I have to say I feel your pain. I'm not trying to do something as ambitious as you (I just wanted something to replace FTP for users that wanted to share files with other users outside of our network), but I've still been frustrated with trying to get the authentication business worked out with different directories having different sets of users that can access them, some with read/write and some with read-only.
To be honest, I've recently started to re-evaluate using DAV for our needs. It just hasn't been as flexible as I had hoped.
-h3
Re:Some of my experiences (Score:2)
After literally years of seeking this information, I've finally found a solution this past week. This is something you have to consider for your users if you're going to use SSL with self-signed certs: how much can they take the constant popup cert warnings and how happy will they be about going through a 8 step process to get rid of it.
===
And that process would be? =)
-ajb
Re:Some of my experiences (Score:2)
Double click on the CA cert that you used to sign your own cert and import it into the right folder when it asks. I think it's 'Trusted Certificates'.
Or you start up 'mmc' and add the Certificate snap in and do it that way. Well, that's how you do it in a Win2k install. The 9x tools probably make this darned near impossible.
Re:Some of my experiences (Score:5, Informative)
I'll be the first to admit that I don't know much about Windows and I'm no export on cryptography so maybe I'm an idiot for not having found a solution sooner. The big hurdle for me was that if I navigated to a site that used one of my own certs, IE would *offer* to add it permanently, walk me through the process, then congratulate me on successfully adding it. But it was all lies. It wasn't added.
As the document above describes (see the 12 step usage section near the middle) the solution I found to work is to convert my openssl CA cert to "DER" format, make that a downloadable file for IE users, and have them *download and open it*. With the proper mime type, this will trigger IE to walk you through exactly the same process as above, but this time it works, suggesting IE really only likes certs in a particular format. No excuse for making up lies, though.
Also, the way I set it up may not work for IE5, but I've had enough for one week
From a personal standpoint, I couldn't care less how IE handles these certs since I don't use it, but I needed to find a solution that our users could handle.
-h3
Re:Some of my experiences (Score:2)
Microsoft's DAV isn't up to snuff (Score:3, Interesting)
In one project I was working on, the DLL driving Web Folders would freeze up Explorer, on a couple of different XP boxes. Frozen. You had to log out to clear it up.
You might want to consider a hybrid approach anyway. WebDAV isn't really a stellar performer, nor is it really designed to be. Why not do Samba, WebDAV, Netatalk, and NFS?
Re:Microsoft's DAV isn't up to snuff (Score:2)
Re:Microsoft's DAV isn't up to snuff (Score:1)
This is just one more reason why IPv6 is a good idea. Simplified routing tables, lots of addresses
There is solution but in apache2 (Score:2, Informative)
WebRFM (Score:2)
"WebRFM implements a virtual-root mechanism, such that each user's access is restricted to his own area (home directory, by default), and it is designed to run in the user's security context (UID/G
perchild MPM (Score:4, Informative)
Re:perchild MPM (Score:2)
Just curious re: the choice of WebDAV (Score:2)
Re:Just curious re: the choice of WebDAV (Score:2)
Each user has a read/write WebDAV folder as well as a read access to a bunch of common areas. The same box also has Samba running, so those of us that are in the offic
davenport (Score:3, Informative)
davenport.sourceforge.net
phpGroupWare (Score:1)
Novell NetDrive = WebDAV and FTP Mount (Score:2)
Works with 98, 2K, and up and allows you to control caching, supports SSL, etc.
Here's a clip that I used to get WebDAV to work while testing. Only use this as a _starting point_ -- I wouldn't trust its security setup for live usage without some tweaking/checking.
-- Replace [ and ]
problem with jigsaw (Score:2)
oops (Score:2)
Novell's implementation of WebDAV (Score:2)
I use Apache+mod_dav on a Linux server, which authenticates against a LDAP server. I dont use mod_digest, but I do everything over https:// so no need for mod digest. We have been using this for last 2 years, wwithout any issues. Very successful too. http://www.xml-dev.com/xml/photo/ [xml-dev.com]