W3C home > Mailing lists > Public > public-ldp@w3.org > January 2015

Re: POSTing to LDPC and security

From: <henry.story@bblfish.net>
Date: Fri, 30 Jan 2015 15:40:12 +0100
Cc: public-ldp@w3.org
Message-Id: <09AC4A34-32FE-499B-9D55-018668604ADA@bblfish.net>
To: Andrei Sambra <andrei@w3.org>

> On 30 Jan 2015, at 15:33, Andrei Sambra <andrei@w3.org> wrote:
> 
> Hi Melvin,
> 
> First of all please bear in mind that the LDP group hasn't really
> tackled this topic. A note [1] was published re. UC&R for LDP and ACLs,
> so you may want to take a look at it. I hope it helps.
> 
> On 1/30/15 6:32 AM, Melvin Carvalho wrote:
>> I'm using an LDPC as a webized version of a UNIX file system
>> 
>> What I do is POST to an LDPC and look for the location field after
>> creating a resource
>> 
>> Then I add an ACL file to control access
>> 
>> However I realized there is a short window where the file might not have
>> the access control I want.  An attacker could subscribe to the container
>> for notifications then intercept the message creating a race condition
> 
> What you're saying is true, but I fear it's more of a theoretical
> problem rather than a practical one. Assuming the server uses HTTPS, an
> attacker won't be able to find out which resource you are creating so
> that they can set an ACL before you do, all in a time frame of about a
> second.

I think we have a method to set default ACLs for created resources.
http://www.w3.org/wiki/WebAccessControl
We should have if not. Something I'd need to check on rww-play.

> 
>> 
>> In the UNIX world inodes and files are closely coupled so the operation
>> is atomic, this is not true in HTTP
>> 
>> Maybe a better idea would be to use the UNIX equivalent of a umask to
>> set default permissions
> 
> Normally, I would expect that a default ACL would be set for the master
> (root) container, blocking write access for everyone.
> 
>> 
>> Any thoughts on this?
> 
> -- Andrei
> 
> [1] http://www.w3.org/TR/ldp-acr/
> 

Social Web Architect
http://bblfish.net/
Received on Friday, 30 January 2015 14:40:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 30 January 2015 14:40:43 UTC