Re: write privileges for owner

[Oliver Zeigermann]

Jason, the collections in users should not be used to store data.
These are not supposed to be the home directory of the specific user,
but are the representation of the user itself.

Oliver


On Wed, 17 Nov 2004 13:54:59 -0500, Jason McElravy
<[EMAIL PROTECTED]> wrote:
> I am hoping to get some clarification on a security configuration for
> slide.  I want each user on my server to have write privileges in his
> "home" directory.  To test this I tried to alter the default domain.xml
> configuration so john could write to /slide/users/john.  I tried
> granting /actions/write to subject owner on /users and set
> inheritable="true".  Here is the snippet:
> 
>  uri="/users">
>  inheritable="true"/>
>  inheritable="true"/>
>  inheritable="true"/>
>  inheritable="true" negative="true"/>
> 
> I set john as the owner of the john directory like this:
> 
>  uri="/users/john">
> 
> 
> http://jakarta.apache.org/slide/";
> name="password">john
> john
> 
> 
> 
> I am able to modify the properties of /users/john under this when
> authenticated as john using this configuration but I get a 403 when I
> try to PUT a file in that directory.  It works if /actions/write is
> granted to /roles/user instead of owner for the /users uri but that
> doesn't meet my requirements.  I want to avoid having to maintain write
> permissions for each user to their home directory like this:
> 
>  uri="/users/john">
>  inheritable="true"/>
> 
>   What am I missing in regard to granting write permissions to the owner
> of a resource?  Thanks in advance for your help.   I am using
> slide-server 2.1b2 and webdavclient 2.1b1.
> 
> -Jason
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: write privileges for owner

[Jason McElravy]

Oliver,

Thanks for the tip on the users collection.  As an alternative,
I created a "john" collection under /files using the following
configuration:







  

john 


   

Unfortunately, I still get a 403 when I try to PUT a file into the john
collection even though I'm authenticated as john and john is the owner
of the collection.  Can anyone offer any clarification as to why this is
the behavior?  I would also welcome alternative suggestions for an
easily maintainable solution to setting up "home" directories for users.
Thanks in advance.

-Jason


-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 17, 2004 6:06 PM
To: Slide Users Mailing List
Subject: Re: write privileges for owner

Jason, the collections in users should not be used to store data.
These are not supposed to be the home directory of the specific user,
but are the representation of the user itself.

Oliver


On Wed, 17 Nov 2004 13:54:59 -0500, Jason McElravy
<[EMAIL PROTECTED]> wrote:
> I am hoping to get some clarification on a security configuration for
> slide.  I want each user on my server to have write privileges in his
> "home" directory.  To test this I tried to alter the default
domain.xml
> configuration so john could write to /slide/users/john.  I tried
> granting /actions/write to subject owner on /users and set
> inheritable="true".  Here is the snippet:
> 
>  uri="/users">
>  inheritable="true"/>
>  inheritable="true"/>
>  inheritable="true"/>
>  inheritable="true" negative="true"/>
> 
> I set john as the owner of the john directory like this:
> 
>  uri="/users/john">
> 
> 
> http://jakarta.apache.org/slide/";
> name="password">john
> john
> 
> 
> 
> I am able to modify the properties of /users/john under this when
> authenticated as john using this configuration but I get a 403 when I
> try to PUT a file in that directory.  It works if /actions/write is
> granted to /roles/user instead of owner for the /users uri but that
> doesn't meet my requirements.  I want to avoid having to maintain
write
> permissions for each user to their home directory like this:
> 
>  uri="/users/john">
>  inheritable="true"/>
> 
>   What am I missing in regard to granting write permissions to the
owner
> of a resource?  Thanks in advance for your help.   I am using
> slide-server 2.1b2 and webdavclient 2.1b1.
> 
> -Jason
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: write privileges for owner

[James Mason]

The "owner" property should be an href referencing the URI of a
principal in the system, eg: /users/john. Check out the
group-member-set properties of the various roles for examples.

-James

On Wed, 2004-11-17 at 21:18 -0500, Jason McElravy wrote:
> Oliver,
> 
>   Thanks for the tip on the users collection.  As an alternative,
> I created a "john" collection under /files using the following
> configuration:
> 
>  uri="/files">
>inheritable="true" negative="true"/>
>inheritable="true"/>
>inheritable="true"/>
>inheritable="true"/>
> 
>uri="/files/john">
>   
>name="owner">john 
>   
>   
>  
> 
> Unfortunately, I still get a 403 when I try to PUT a file into the john
> collection even though I'm authenticated as john and john is the owner
> of the collection.  Can anyone offer any clarification as to why this is
> the behavior?  I would also welcome alternative suggestions for an
> easily maintainable solution to setting up "home" directories for users.
> Thanks in advance.
> 
> -Jason
> 
> 
> -Original Message-
> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 17, 2004 6:06 PM
> To: Slide Users Mailing List
> Subject: Re: write privileges for owner
> 
> Jason, the collections in users should not be used to store data.
> These are not supposed to be the home directory of the specific user,
> but are the representation of the user itself.
> 
> Oliver
> 
> 
> On Wed, 17 Nov 2004 13:54:59 -0500, Jason McElravy
> <[EMAIL PROTECTED]> wrote:
> > I am hoping to get some clarification on a security configuration for
> > slide.  I want each user on my server to have write privileges in his
> > "home" directory.  To test this I tried to alter the default
> domain.xml
> > configuration so john could write to /slide/users/john.  I tried
> > granting /actions/write to subject owner on /users and set
> > inheritable="true".  Here is the snippet:
> > 
> >  > uri="/users">
> >  > inheritable="true"/>
> >  > inheritable="true"/>
> >  > inheritable="true"/>
> >  > inheritable="true" negative="true"/>
> > 
> > I set john as the owner of the john directory like this:
> > 
> >  > uri="/users/john">
> > 
> > 
> > http://jakarta.apache.org/slide/";
> > name="password">john
> >  name="owner">john
> > 
> > 
> > 
> > I am able to modify the properties of /users/john under this when
> > authenticated as john using this configuration but I get a 403 when I
> > try to PUT a file in that directory.  It works if /actions/write is
> > granted to /roles/user instead of owner for the /users uri but that
> > doesn't meet my requirements.  I want to avoid having to maintain
> write
> > permissions for each user to their home directory like this:
> > 
> >  > uri="/users/john">
> >  > inheritable="true"/>
> > 
> >   What am I missing in regard to granting write permissions to the
> owner
> > of a resource?  Thanks in advance for your help.   I am using
> > slide-server 2.1b2 and webdavclient 2.1b1.
> > 
> > -Jason
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: write privileges for owner

[Jason McElravy]

I tried setting the owner of the collection as you said but using the
webDAV client I got:

$ propget john owner
Getting properties '/slide/files/john': /slide/users//users/john

I switched back to the other way and put some debug lines in the
matchOwner method of ACLSecurityImpl and the owner of the resource is
being recognized fine so that's not the issue. 

 I added some additional debug lines to gather some more information.
Here is my test scenario:

/actions/write is granted to "owner" of /files and is inheritable
The /files/john collection has an "owner" set to /users/john
The /files/john collection is empty
I am authenticated as john
I try to PUT test.txt into /files/john

In this scenario I get a 403.  I put in some debug lines and found that
the 403 is being thrown because the security implementation is trying to
enforce /actions/write privileges for /users/john on
/files/john/test.txt which does not exist yet.  This behavior doesn't
jive with the method privilege table in the webDAV access control
extension
(http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#rfc.
section.B)
 Which says that when doing a PUT and the target resource does not
exist, you need  privileges on the parent collection of the
target.  Using these guidelines, in my scenario the PUT should succeed
by virtue of john having /actions/write privileges on the parent
directory /files/john.  

Is this a bug in the implementation?  Would an alternative be to set the
owner on the new resource prior to the security checks?  Any other
thoughts?  Thanks in advance.

Jason 

-Original Message-
From: James Mason [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 17, 2004 11:37 PM
To: Slide Users Mailing List
Subject: RE: write privileges for owner

The "owner" property should be an href referencing the URI of a
principal in the system, eg: /users/john. Check out the
group-member-set properties of the various roles for examples.

-James

On Wed, 2004-11-17 at 21:18 -0500, Jason McElravy wrote:
> Oliver,
> 
>   Thanks for the tip on the users collection.  As an alternative,
> I created a "john" collection under /files using the following
> configuration:
> 
>  uri="/files">
>inheritable="true" negative="true"/>
>inheritable="true"/>
>inheritable="true"/>
>inheritable="true"/>
> 
>uri="/files/john">
>   
>name="owner">john 
>   
>   
>  
> 
> Unfortunately, I still get a 403 when I try to PUT a file into the
john
> collection even though I'm authenticated as john and john is the owner
> of the collection.  Can anyone offer any clarification as to why this
is
> the behavior?  I would also welcome alternative suggestions for an
> easily maintainable solution to setting up "home" directories for
users.
> Thanks in advance.
> 
> -Jason
> 
> 
> -Original Message-
> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 17, 2004 6:06 PM
> To: Slide Users Mailing List
> Subject: Re: write privileges for owner
> 
> Jason, the collections in users should not be used to store data.
> These are not supposed to be the home directory of the specific user,
> but are the representation of the user itself.
> 
> Oliver
> 
> 
> On Wed, 17 Nov 2004 13:54:59 -0500, Jason McElravy
> <[EMAIL PROTECTED]> wrote:
> > I am hoping to get some clarification on a security configuration
for
> > slide.  I want each user on my server to have write privileges in
his
> > "home" directory.  To test this I tried to alter the default
> domain.xml
> > configuration so john could write to /slide/users/john.  I tried
> > granting /actions/write to subject owner on /users and set
> > inheritable="true".  Here is the snippet:
> > 
> >  > uri="/users">
> >  > inheritable="true"/>
> >  > inheritable="true"/>
> >  > inheritable="true"/>
> >  > inheritable="true" negative="true"/>
> > 
> > I set john as the owner of the john directory like this:
> > 
> >  > uri="/users/john">
> > 
> > 
> > http://jakarta.apache.org/slide/";
> > name="password">john
> >  name="owner">john
> > 
> > 
> > 
> > I am able to modify the properties of /users/john under this 

RE: write privileges for owner

[Chris O'Connell]

Sorry for what may be a newbie question, but can someone point me at a 'getting 
started' link.  I've downloaded the server and client and the documentation and 
I'm trying to go through it, but I think I'm just missing something real basic. 
 For example, I think I need to use the 'WebdavResource' class in my client to 
access my store.  But I can't figure out the big picture of how to use this 
class.  Am I just simple?  Any help would be appreciated.

Thanks in advance, Chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: write privileges for owner

[Mirko Froehlich]

Hi Chris,

The Wiki is your best bet: 

The following page describes how to obtain a WebdavResource:


Once you have this, the Javadocs should help you access the repository
through the WebdavResource. One thing I found very confusing at first is
that the responsibility of the WebdavResource is not quite clear. On the
one hand, it acts as an entity that represents an actual resource
(document or folder) in the repository. Unfortunately, it also acts as a
general facade into the repository, for example by providing methods
that take a path as a parameter and act on the resource corresponding to
that path.

If you keep this in mind, you should be able to get everything done,
though.

-Mirko


On Fri, 2004-11-19 at 13:02, Chris O'Connell wrote:

> Sorry for what may be a newbie question, but can someone point me at a 
> 'getting started' link.  I've downloaded the server and client and the 
> documentation and I'm trying to go through it, but I think I'm just missing 
> something real basic.  For example, I think I need to use the 
> 'WebdavResource' class in my client to access my store.  But I can't figure 
> out the big picture of how to use this class.  Am I just simple?  Any help 
> would be appreciated.
> 
> Thanks in advance, Chris

RE: write privileges for owner

[James Mason]

This sounds like a bug.

You say it works if you grant write /roles/users? How does the logic in
SecurityImpl differ in that case?

-James

On Fri, 2004-11-19 at 16:00 -0500, Jason McElravy wrote:
> I tried setting the owner of the collection as you said but using the
> webDAV client I got:
> 
> $ propget john owner
> Getting properties '/slide/files/john': /slide/users/ xmlns:D='DAV:'>/users/john
> 
> I switched back to the other way and put some debug lines in the
> matchOwner method of ACLSecurityImpl and the owner of the resource is
> being recognized fine so that's not the issue. 
> 
>  I added some additional debug lines to gather some more information.
> Here is my test scenario:
> 
> /actions/write is granted to "owner" of /files and is inheritable
> The /files/john collection has an "owner" set to /users/john
> The /files/john collection is empty
> I am authenticated as john
> I try to PUT test.txt into /files/john
> 
> In this scenario I get a 403.  I put in some debug lines and found that
> the 403 is being thrown because the security implementation is trying to
> enforce /actions/write privileges for /users/john on
> /files/john/test.txt which does not exist yet.  This behavior doesn't
> jive with the method privilege table in the webDAV access control
> extension
> (http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#rfc.
> section.B)
>  Which says that when doing a PUT and the target resource does not
> exist, you need  privileges on the parent collection of the
> target.  Using these guidelines, in my scenario the PUT should succeed
> by virtue of john having /actions/write privileges on the parent
> directory /files/john.  
> 
> Is this a bug in the implementation?  Would an alternative be to set the
> owner on the new resource prior to the security checks?  Any other
> thoughts?  Thanks in advance.
> 
> Jason 
> 
> -Original Message-
> From: James Mason [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 17, 2004 11:37 PM
> To: Slide Users Mailing List
> Subject: RE: write privileges for owner
> 
> The "owner" property should be an href referencing the URI of a
> principal in the system, eg: /users/john. Check out the
> group-member-set properties of the various roles for examples.
> 
> -James
> 
> On Wed, 2004-11-17 at 21:18 -0500, Jason McElravy wrote:
> > Oliver,
> > 
> > Thanks for the tip on the users collection.  As an alternative,
> > I created a "john" collection under /files using the following
> > configuration:
> > 
> >  > uri="/files">
> >  > inheritable="true" negative="true"/>
> >  > inheritable="true"/>
> >  > inheritable="true"/>
> >  > inheritable="true"/>
> > 
> >  > uri="/files/john">  
> > 
> >  > name="owner">john 
> > 
> > 
> >
> > 
> > Unfortunately, I still get a 403 when I try to PUT a file into the
> john
> > collection even though I'm authenticated as john and john is the owner
> > of the collection.  Can anyone offer any clarification as to why this
> is
> > the behavior?  I would also welcome alternative suggestions for an
> > easily maintainable solution to setting up "home" directories for
> users.
> > Thanks in advance.
> > 
> > -Jason
> > 
> > 
> > -Original Message-
> > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
> > Sent: Wednesday, November 17, 2004 6:06 PM
> > To: Slide Users Mailing List
> > Subject: Re: write privileges for owner
> > 
> > Jason, the collections in users should not be used to store data.
> > These are not supposed to be the home directory of the specific user,
> > but are the representation of the user itself.
> > 
> > Oliver
> > 
> > 
> > On Wed, 17 Nov 2004 13:54:59 -0500, Jason McElravy
> > <[EMAIL PROTECTED]> wrote:
> > > I am hoping to get some clarification on a security configuration
> for
> > > slide.  I want each user on my server to have write privileges in
> his
> > > "home" directory.  To test this I tried to alter the default
> > domain.xml
> > > configuration so john could write to /slide/users/john.  I tried
> > > granting /actions/write to subject owner on /users and set
> > > inheritable="true&q

RE: write privileges for owner

[Jason McElravy]

In AclSecurityImpl.evaluateAcl() when checking to see if /users/john can
/actions/write resource /files/john/test.txt, the code finds a
permissions match on the following permission (output is from the
toString method):
permission=[object=/files/john, subject=/roles/user,
action=/actions/write, ->GRANT]
because john has both /action/write permissions and matches the role of
/roles/user but it doesn't find a match when the subject is owner
because it only finds a match on the /action/write permission.  The
match on the subject fails because john is not yet the owner of
/files/john/test.txt from what I can see.  Since /files/john/test.txt is
a new resource, the check should only be on /files/john.

Jason 
-Original Message-
From: James Mason [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 19, 2004 11:14 PM
To: Slide Users Mailing List
Subject: RE: write privileges for owner

This sounds like a bug.

You say it works if you grant write /roles/users? How does the logic in
SecurityImpl differ in that case?

-James

On Fri, 2004-11-19 at 16:00 -0500, Jason McElravy wrote:
> I tried setting the owner of the collection as you said but using the
> webDAV client I got:
> 
> $ propget john owner
> Getting properties '/slide/files/john': /slide/users/ xmlns:D='DAV:'>/users/john
> 
> I switched back to the other way and put some debug lines in the
> matchOwner method of ACLSecurityImpl and the owner of the resource is
> being recognized fine so that's not the issue. 
> 
>  I added some additional debug lines to gather some more information.
> Here is my test scenario:
> 
> /actions/write is granted to "owner" of /files and is inheritable
> The /files/john collection has an "owner" set to /users/john
> The /files/john collection is empty
> I am authenticated as john
> I try to PUT test.txt into /files/john
> 
> In this scenario I get a 403.  I put in some debug lines and found
that
> the 403 is being thrown because the security implementation is trying
to
> enforce /actions/write privileges for /users/john on
> /files/john/test.txt which does not exist yet.  This behavior doesn't
> jive with the method privilege table in the webDAV access control
> extension
>
(http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#rfc.
> section.B)
>  Which says that when doing a PUT and the target resource does not
> exist, you need  privileges on the parent collection of the
> target.  Using these guidelines, in my scenario the PUT should succeed
> by virtue of john having /actions/write privileges on the parent
> directory /files/john.  
> 
> Is this a bug in the implementation?  Would an alternative be to set
the
> owner on the new resource prior to the security checks?  Any other
> thoughts?  Thanks in advance.
> 
> Jason 
> 
> -----Original Message-
> From: James Mason [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 17, 2004 11:37 PM
> To: Slide Users Mailing List
> Subject: RE: write privileges for owner
> 
> The "owner" property should be an href referencing the URI of a
> principal in the system, eg: /users/john. Check out
the
> group-member-set properties of the various roles for examples.
> 
> -James
> 
> On Wed, 2004-11-17 at 21:18 -0500, Jason McElravy wrote:
> > Oliver,
> > 
> > Thanks for the tip on the users collection.  As an alternative,
> > I created a "john" collection under /files using the following
> > configuration:
> > 
> >  > uri="/files">
> >  > inheritable="true" negative="true"/>
> >  > inheritable="true"/>
> >  > inheritable="true"/>
> >  > inheritable="true"/>
> > 
> >  > uri="/files/john">  
> > 
> >  > name="owner">john 
> > 
> > 
> >
> > 
> > Unfortunately, I still get a 403 when I try to PUT a file into the
> john
> > collection even though I'm authenticated as john and john is the
owner
> > of the collection.  Can anyone offer any clarification as to why
this
> is
> > the behavior?  I would also welcome alternative suggestions for an
> > easily maintainable solution to setting up "home" directories for
> users.
> > Thanks in advance.
> > 
> > -Jason
> > 
> > 
> > -Original Message-
> > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
> > Sent: Wednesday, November 17, 2004 6:06 PM
> > To: Slide Users Mailing Li

RE: write privileges for owner

[James Mason]

I've created a bug entry for this:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32352

-James

On Sat, 2004-11-20 at 00:13 -0500, Jason McElravy wrote:
> In AclSecurityImpl.evaluateAcl() when checking to see if /users/john can
> /actions/write resource /files/john/test.txt, the code finds a
> permissions match on the following permission (output is from the
> toString method):
> permission=[object=/files/john, subject=/roles/user,
> action=/actions/write, ->GRANT]
> because john has both /action/write permissions and matches the role of
> /roles/user but it doesn't find a match when the subject is owner
> because it only finds a match on the /action/write permission.  The
> match on the subject fails because john is not yet the owner of
> /files/john/test.txt from what I can see.  Since /files/john/test.txt is
> a new resource, the check should only be on /files/john.
> 
> Jason 
> -Original Message-
> From: James Mason [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 19, 2004 11:14 PM
> To: Slide Users Mailing List
> Subject: RE: write privileges for owner
> 
> This sounds like a bug.
> 
> You say it works if you grant write /roles/users? How does the logic in
> SecurityImpl differ in that case?
> 
> -James
> 
> On Fri, 2004-11-19 at 16:00 -0500, Jason McElravy wrote:
> > I tried setting the owner of the collection as you said but using the
> > webDAV client I got:
> > 
> > $ propget john owner
> > Getting properties '/slide/files/john': /slide/users/ > xmlns:D='DAV:'>/users/john
> > 
> > I switched back to the other way and put some debug lines in the
> > matchOwner method of ACLSecurityImpl and the owner of the resource is
> > being recognized fine so that's not the issue. 
> > 
> >  I added some additional debug lines to gather some more information.
> > Here is my test scenario:
> > 
> > /actions/write is granted to "owner" of /files and is inheritable
> > The /files/john collection has an "owner" set to /users/john
> > The /files/john collection is empty
> > I am authenticated as john
> > I try to PUT test.txt into /files/john
> > 
> > In this scenario I get a 403.  I put in some debug lines and found
> that
> > the 403 is being thrown because the security implementation is trying
> to
> > enforce /actions/write privileges for /users/john on
> > /files/john/test.txt which does not exist yet.  This behavior doesn't
> > jive with the method privilege table in the webDAV access control
> > extension
> >
> (http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#rfc.
> > section.B)
> >  Which says that when doing a PUT and the target resource does not
> > exist, you need  privileges on the parent collection of the
> > target.  Using these guidelines, in my scenario the PUT should succeed
> > by virtue of john having /actions/write privileges on the parent
> > directory /files/john.  
> > 
> > Is this a bug in the implementation?  Would an alternative be to set
> the
> > owner on the new resource prior to the security checks?  Any other
> > thoughts?  Thanks in advance.
> > 
> > Jason 
> > 
> > -Original Message-
> > From: James Mason [mailto:[EMAIL PROTECTED] 
> > Sent: Wednesday, November 17, 2004 11:37 PM
> > To: Slide Users Mailing List
> > Subject: RE: write privileges for owner
> > 
> > The "owner" property should be an href referencing the URI of a
> > principal in the system, eg: /users/john. Check out
> the
> > group-member-set properties of the various roles for examples.
> > 
> > -James
> > 
> > On Wed, 2004-11-17 at 21:18 -0500, Jason McElravy wrote:
> > > Oliver,
> > > 
> > >   Thanks for the tip on the users collection.  As an alternative,
> > > I created a "john" collection under /files using the following
> > > configuration:
> > > 
> > >  > > uri="/files">
> > >> > inheritable="true" negative="true"/>
> > >> > inheritable="true"/>
> > >> > inheritable="true"/>
> > >> > inheritable="true"/>
> > > 
> > >> > uri="/files/john">
> > >   
> > >            > > name="owner">john 
> > >   
> > >   
> > >  
> > > 
&g