Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Apache Software

Implementing True WebDAV Homedirs? 47

Vito asks: "I'd like to use WebDAV over SSL (with [preferably digest] authentication against Unix accounts) to provide a few hundred Windows users with secure, easy, and free access to their Linux home directories. WebDAV is supported as Web Folders in Windows, meaning there is no need to download and install SFTP, SCP, FTPS, and other clients. It's also supported natively in Mac OS X, and Linux users can install davfs. But this setup doesn't seem to be possible (safely) using Apache. Do I have alternatives?"

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

This discussion has been archived. No new comments can be posted.

Implementing True WebDAV Homedirs?

Comments Filter:
  • mod_become (Score:5, Interesting)

    by danpat ( 119101 ) on Thursday July 24, 2003 @10:52PM (#6528748) Homepage

    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)

      by More Trouble ( 211162 ) on Thursday July 24, 2003 @10:57PM (#6528774)
      We do something very similar to this for AFS access, using a module called "web aklog". aklog is an AFS tool for giving a process group "tokens" to talk to AFS servers on behalf of the user. The concept of "root" is meaningless in AFS, so this is a pretty secure methodology. Doesn't really help if you're trying to serve the local filesystem, tho.

      :w
    • chroot'ed, your exposure amounts to the possibility that
      a remote exploit can allow a cracker to write on /home
      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.
      • I thought root shoiuld be to break out of a chroot jail.
      • chroot'ed, your exposure amounts to the possibility that a remote exploit can allow a cracker to write on /home as root.

        Wrong. Any root process can break out of a chroot jail. chroot only protects non-root processes.
  • by Anonymous Coward

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

  • by GiMP ( 10923 )
    Roll Your Own. It will have to run as root, but it could change the userid as required.
  • won't work? (Score:2, Interesting)

    by tzanger ( 1575 )

    It's kind of a nasty hack, but won't this work?

    <Location /user1>
    require user user1
    </Location>

    <Location /user2>
    require user user2
    </Location>

    <Location /user3>
    require user user3
    </Location>
    ??
    • But this doesn't address the file permissions. If you're running apache as user www, then at the file system level you won't have the correct access to homedirs.

      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 :)
      • you could set up a folder in each users homedir that is accessable by webdav.

        set up a webdav folder and give each user their own dir

        /var/www/homedir/user1
        /var/www/homedir/user2
        /var/www/homedir/user3

        chown it www chgrp webdavusers

        ln -s /home/user1/dav /var/www/homedir/user1

        And viola, roberts your fathers brother
        • And that will work...

          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.

          • well i've had it working.

            If it was 660, how would the webserver get access? Eitherway, make users part of www group
            • But then all users can read all other users files, and that is never a good thing :)
              • how is that different than a windows box?

                :)

                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

          • It'll work. Use something like the following:

            <Location /user/harvey.wallbanger>
            <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.
          • gadzooks!

            Sorry. Too much Chimay last night.

            I seem to have missed the part about chowning and chgrouping.

            Ah well.
          • So... Go to acl.bestbits.at and get the ACL patches for your kernel (or switch to 2.5/2.6 which supports it out of the box).
            Have the user own the files but use ACLs to give the apache user access to read/write/create the files.
        • 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

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

            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)

        by tres ( 151637 )
        Is that even possible?

        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 .Mac services, but .Mac does
        • Yeah, it likely is a nightmare.

          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).
  • by Arkham ( 10779 )
    Could you couple WebDAV with SSH to achieve the requisite security?
    • Could you couple WebDAV with SSH to achieve the requisite security?

      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.
  • by h3 ( 27424 ) on Friday July 25, 2003 @12:10AM (#6529226) Homepage Journal
    WebDAV is supported as Web Folders in Windows, meaning there is no need to download and install SFTP, SCP, FTPS, and other clients. It's also supported natively in Mac OS X

    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 :p.

    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
    • ===
      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
      • And that process would be? =)


        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.
      • by h3 ( 27424 ) on Friday July 25, 2003 @03:09AM (#6529933) Homepage Journal
        Sorry, I was too busy ranting and forgot to elaborate. Here's a page where I was tipped off http://www.drh-consultancy.demon.co.uk/pkcs12faq.h tml [demon.co.uk]

        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 :p. MacIE - hopeless. No way to import certs as far as I know.

        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
        • Of course, you have know way of ensuring that the certificate isn't tampered with before or during the download. (You could send some kind of digest by a secure channel, but then I don't think IE shows digests.)
  • by bpendleton ( 139658 ) on Friday July 25, 2003 @01:23AM (#6529565) Homepage
    Surprisingly, even though they had a pretty big hand in publishing the WebDAV standard, Microsoft's implementations are pretty poor. Depending on whether or not certain other packages are installed (mostly anything that talks Frontpage), and service release levels, there are several different sets of behaviors/bugs you can encounter with the Web Folders implementation.

    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?
    • HTTP (WebDAV) will peirce most firewalls, but SMB requires a standard port and NFS requires UDP (normally, I haven't used TCP/NFS) and I don't know that either can be run over SSL. Stacking SMB on a secure connection can be done, but it requires not sharing from the client, which isn't always practical. Joe
      • You're right, DAV is easier to tunnel... but that's one of the reasons why it's performance, in general, is going to be problematic. Doing all of your work over one-off TCP connections can introduce a lot of lag, if you're doing a lot of file manipulation. I would never want to mount my environment's home directory that way, for instance. The pure number of .config files that get loaded would choke the system.

        This is just one more reason why IPv6 is a good idea. Simplified routing tables, lots of addresses
  • apache 2 supports prechild MPM: "Multi-Processing Module allowing for daemon processes serving requests to be assigned a variety of different userids" Here is link: perchild [apache.org] It solves your uids permission part of a problem.
  • Have you looked at WebRFM [geocities.com]? It seems old and abandoned (home page gone, mirror remains) but they implemented it on a server at my uni just this year. The "visible" part of WebRFM is web-based file browser but this does include the code to get the per-user stuff happening. Here's the relevant bit from the web page:

    "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)

    by Hard_Code ( 49548 ) on Friday July 25, 2003 @11:32AM (#6532352)
    You could try Apache 2.0 with perchild MPM which allows requests to be served under arbitrary user ids... (no suid,suexec crap)
    • It would be perfect, if it could serve more than 5 pages before hanging solid. The perchild MPM is unsupported, and development on it has pretty much halted. The Apache developers are working on something else similar, but it isn't near complete.
  • Just curious why you chose WebDAV over Samba/Netatalk for doing this.
    • I can't speak for the dude that posted the article, but I went with WebDAV because I have a lot of remote users that I need to support. I wanted everyone to have a place to put stuff, but I also wanted the connection to be encrypted somehow. It could be that I'm an idiot, but I had a real hard time trying to get ssl over ftp to work reliably.

      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)

    by Dark Fire ( 14267 ) <clasmc@RABBITgmail.com minus herbivore> on Friday July 25, 2003 @12:15PM (#6532752)
    If you are using samba, you might want to try using davenport. Davenport offers a read only listing of files in your browser and permits read/write via webdav. davenport converts webdav requests to smb requests via the jcifs project. Davenport is a java servlet.

    davenport.sourceforge.net

  • has a filemanager with user/group permissions www.phpgroupware.org
  • Check out Novell NetDrive. It's available as a free download right here support.novell.com/servlet/filedownload/uns/pub/n e tdrv41.exe/ [216.239.37.104] and allows you to mount FTP servers, WebDAV shares, and iFolders as local Windows drives.

    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 ]
  • the WebDAV server is separately maintained from the regular server, and is a revision or two behind. Maybe it's usable, but it's not the target of their main development efforts, it appears.
  • Netware fully supports WebDAV protocol to access their file shares on the Netware Servers. They use mod_dav+Apache for providing the access. There is a elaborate GUI to control access.
    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]

"If it ain't broke, don't fix it." - Bert Lantz

Working...