434581 - Ability to write out .htaccess files when sharing bookmarks

Status: RESOLVED FIXED

(Cloud Services :: General, defect, P1)

Description

[Dan Mills [:thunder]]

The Weave server (services.m.c) allows the use of .htaccess files to set access permissions.  The Weave add-on could use this to share bookmarks with other users.

Some things to keep in mind:

1) .htaccess files are apache config files, and as such should be locked down to only allow what we need in them.
2) Ideally only the owner of the account would be able to see the .htaccess file for a shared directory.  Otherwise others can see what accounts you have shared with (and while that may be desirable later, it is better to allow this deliberately).
3) In the future we may want to move to an application server, rather than staying on dumb storage.  Therefore, we might want to keep the data easy-to-parse in case we decide to do a migration to a central database.

I'm not sure what .htaccess settings we will need, that will require some research.

Comment 1

[Dan Mills [:thunder]]

Alternatively, we could have a server process to create/manage .htaccess files, and expose an API to the add-on with simpler semantics (like share(file, user) or revoke(file, user), etc).

Reparenting this bug to the server work.

Comment 2

[Atul Varma [:atul]]

At present users do have .htaccess files, but it's not possible to actually access them via WebDAV, so we're probably going to be going into the alternative that Dan proposed in comment #1.  I think Chris Beard is looking into this.

Comment 3

[Atul Varma [:atul]]

I'm going to argue for the RESTful API Dan proposed in comment #1 for
these reasons:

  * It decouples Weave from Apache, allowing other WebDAV servers that
    don't use .htaccess files to be used.  They just need to
    implement their own RESTful API.

  * It's a "thinner" API than .htaccess files; .htaccess files can do
    lots of things that aren't relevant to weave and could be
    exploited by users or accidentally changed to cause unexpected
    behavior, whereas a simple RESTful API geared solely towards what
    people need to do with Weave has much smaller scope and is
    therefore simpler and less prone to malfunction/exploitation.

  * Creating a RESTful API essentially delegates the act of creating
    and manipulating .htaccess files to the server.  Since the
    .htaccess-manipulating code is on the server instead of the
    client, any bugs in it can be easily fixed and instantly propogate
    out to all clients, whereas fixing a bug in the client will
    require a redeployment of client code that will inconvenience
    users by requiring them to restart their browser and also not take
    effect immediately.

Comment 4

[Dan Mills [:thunder]]

I agree with comment #3.
I believe Chris is working on this and may have something already implemented.

Comment 5

[Atul Varma [:atul]]

Assuming the user is named 'foo', the following .htaccess file should be used for a user's root directory:

Options +Indexes
Require	user foo

And this should be in their 'public' directory:

<Limit GET PROPFIND>
Require	valid-user
</Limit>
<LimitExcept GET PROPFIND>
Require user foo
</LimitExcept>

That allows any valid Weave/LDAP user to retrieve resources from the public directory, but only allows the owner to write to it (e.g., using PUT, POST, etc), and it allows only the owner to have read/write access to their root directory.  I tried this out manually and it works as expected.

Thunder and I discussed what the RESTful API should be and determined that there are two major types of instructions that can be issued:

  SHARE <resource> WITH <user>
  UNSHARE <resource> WITH <user>

I recommend that these operations be done via an HTTP POST; even though it's more inconvenient to implement, it makes sense as a POST because the user is modifying the server when issuing the command.  Making this a GET could result in unintentional security vulnerabilities in the future, e.g. if we assume in a .htaccess that a GET request won't modify the server when in reality it does.

Comment 6

[Atul Varma [:atul]]

Erm, perhaps those .htaccess templates aren't the best things to use.  I'm actually able to upload PHP files to my user directory on the dev server and execute them, which isn't a good sign.

Fortunately, this vulnerability doesn't exist on services.mozilla.com.

Comment 7

[Dan Mills [:thunder]]

This is done and working in the 0.2 server.