[Fwd: Re: ACL for subtrees]

-------- Messaggio Originale  --------
Oggetto: Re: ACL for subtrees
Data: Sat, 5 Mar 2005 18:00:42 -0500
Da: Eric Prud'hommeaux <eric@w3.org>
A: Stefano Debenedetti <ste@demaledetti.net>
CC: Dominique Dominique Hazaël-Massieux <dom@w3.org>, w3-archive@w3.org
Referenze: <42234CC3.4090402@demaledetti.net>

cc:ing dom to make sure he can catch an lies i tell

On Mon, Feb 28, 2005 at 05:54:27PM +0100, Stefano Debenedetti wrote:
> Hello,
> 
> I am interested in building something similar to the W3C ACL model in OWL 
> for the prototype RDF-enabled web server I am working on (which will be 
> released with open source license when ready).
> 
> I found that this page:
> 
> http://www.w3.org/2002/02/auto-acl
> 
> linked from this page:
> 
> http://www.w3.org/2001/04/20-ACLs.html,access
> 
> is not world-readable.

'tis now, but it will require a bit of explanation.

> I am very interested at how you solved the subtree issue for the following 
> reasons:
> 
> - RDF/OWL doesn't make it very easy to address multiple resources at once
> - RDF/OWL doesn't make it very easy to address undetermined resources (eg. 
> everything below this root address)

all our RDF ACL assertions are in a very simple form:

<r:RDF xml:base="http://www.w3.org/2001/02/acls/ns"
 xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:s="http://www.w3.org/2001/02/acls/ns#">
   <s:resourceAccessRule>
      <s:accessor r:resource="http://www.w3.org/Systems/db/webId?all=all" />
      <s:access r:resource="#racl" />
      <s:access r:resource="#head" />
      <s:access r:resource="#get" />
      <s:access r:resource="#options" />
      <s:access r:resource="#trace" />
      <s:hasAccessTo r:resource="http://www.w3.org/2001/04/20-ACLs.html" />
   </s:resourceAccessRule>
   <s:resourceAccessRule>
      <s:accessor r:resource="http://www.w3.org/Systems/db/webId?group=w3t_passwords" />
      <s:access r:resource="#chacl" />
      <s:access r:resource="#racl" />
      <s:access r:resource="#head" />
      <s:access r:resource="#get" />
      <s:access r:resource="#put" />
      <s:access r:resource="#delete" />
      <s:access r:resource="#connect" />
      <s:access r:resource="#options" />
      <s:access r:resource="#trace" />
      <s:hasAccessTo r:resource="http://www.w3.org/2001/04/20-ACLs.html" />
   </s:resourceAccessRule>
</r:RDF>

*note, this is a recent update. I finally got around to bringing it up
to date with a modern RDF parser (and serializer).

We don't express our recursive rules in RDF. Instead, we create a
.default-acl file. I guess the cvs commit backend walks up the
directory tree to the tightest containing directory with a
.default-acl (most often there is none) and sets newly created
documents to that ACL.

The ACL system is very flexible; it allows arbitrary sets of
permissions for any set of groups or prinpals. However, 99.9% of its
use is to select one of 5 "macros" which correspond to the notional
access levels we had in our old apache access control systems
(mod_auth_cern). Macros like "Team", "Member", "World" ... seem to
cover most of our needs.

The announcement to the team didn't seem terribly confidential so here
'tis:
[[
...
I've implemented the idea I had to make this possible, and now, you
should be able to get what you wanted by creating a ".default-acl" file
in the directory, containing either "Team", "Public" or "Member"; any
new files added in this directory will then be acl'd accordingly.

A few notes:
- it only works in ACL space (duh)
- it only works for files committed after or at the same time as the
.default-acl file
- it's dumb, so if you change the value in .default-acl or if you remove
the file, that won't have any effect; you need to contact webreq to
actually change the default acl
]]

If you are likely to re-use the system, I can put a bit of effort into packaging documentation. Our authoritative ACLs are stored in a normalized SQL and can be queried with a special apache module which was written for apach1.3 and apache2 [AP2]. 

> - I would like my server's users to be able to allow access to a resource 
> that is located somewhere deepely inside a non-accessible tree (e.g. I want 
> to be able to specify that by default /home/user and everything below it is 
> not readable but /home/user/public_html and everything below it is)

There are groups called "All" and "None". The latter has had very
little excercise but it sounds like your site might be appropriate.

> As I think that your work is among the most interesting content available 
> on the W3C site (ACL, RNodes, XML Pipelines, ...), I would greatly 
> appreciate if you could grant world access on any work related to the 
> subtree access control topic (or send me a copy and paste :)

tx for the vote of confidence, but i'll still only do the work if
there is a likelyhood you'll make use of it. if there is, i'd like to
see someone else make use of the investment.

i've considered getting this all together for an apachecon talk. if we
do the work and you role this out on another site, perhaps you could
do the talk. while you're poking around, it would be handy if you
could keep track of pages with redundant or obselete info. that way
i'd have an easier time making one world-readable document that
described the system in detail and was enough to get a working version
running.

[AP2] http://dev.w3.org/cvsweb/2002/httpExt/apache_2/httpd-2.0/modules/w3c/
-- 
have fun,
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.