You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Oliver Zeigermann <ol...@gmail.com> on 2004/10/19 15:07:52 UTC
Suspicious code in MacroImpl deleteObject
While working on the MacroStore implementation I discovered code in
MacroImpl deleteObject that looks suspicious to me. It revokes all
permissions and locks before trying to delete something and
additionally seems to remove all versions as well.
Could someone confirm this is indeed the case and if so, why?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Suspicious code in MacroImpl deleteObject
Posted by Jim Myers <ji...@verizon.net>.
Yeah - that, or some means of asking for permissions before you actually try
to do the operation:
request authorization to remove permissions
delete content
revokePermissions as previously authorized
Probably easier to just delete at the store level unless there's a more
general reason to be able to request authorizations up front in a
transaction (and I can't think of a good one right now, though some form of
cached effective permissions might make this route easier ...)
Jim
----- Original Message -----
From: "Oliver Zeigermann" <ol...@gmail.com>
To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>; "Jim
Myers" <ji...@verizon.net>
Sent: Tuesday, October 19, 2004 1:16 PM
Subject: Re: Suspicious code in MacroImpl deleteObject
Wouldn't it be possible to first delete the content and node
information and then delete permission and locking *directly* on the
store that contained the object? Without going through the helpers?
Oliver
On Tue, 19 Oct 2004 13:12:06 -0400, Jim Myers <ji...@verizon.net> wrote:
> Oliver,
>
> Not sure it applies here, but I remember looking around one time and
> discovering that removing permissions ends up checking to see if the
> object
> exists, so if they aren't removed before the object is deleted, you get
> errors. revokePermission() has a call to checkCredentials(token, object,
> ...) in it. For slide 1, I think we kludged and silently caught the
> ObjectNotFoundException caused by Macro.delete().
>
> With a quick look in MacroImpl, I'm don't see any way that a security
> setting on the node being delted is getting checked either, but a fix will
> probably have to do more than just remove content and then the
> permissions...
>
> Jim
>
>
>
>
> ----- Original Message -----
> From: "Oliver Zeigermann" <ol...@gmail.com>
> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> Sent: Tuesday, October 19, 2004 11:32 AM
> Subject: Re: Suspicious code in MacroImpl deleteObject
>
> On Tue, 19 Oct 2004 16:44:36 +0200, Stefan Lützkendorf
> <lu...@apache.org> wrote:
> >
> > Versions are maintained at the version history resource I think. That
> > one of the things im bewildered again and again (:-)
> > If you put a resource under version control and check it in some times,
> > you will not found any aditional revisiondescriptor at the resource but
> > at the history resource. So I think (webdav) versions are NOT removed.
> > (Multiple revisions I have ever observerd when removing the history
> > resource, i.e. the collection where the versions are stored) (Thats why
> > think the webdav versioning and the slide versioning are designed under
> > different views, and something could be improved we only want to support
> > webdav)
>
> Right, forgot about that...
>
> > The other point looks weired too. First locka and permissions are
> > removed, and than content and the node are removed. The checks in
> > ContentImpl.remove and StructureImpl.remove seem to be made effectless.
> > But why we dont observe strange security violations?
>
> I guess because inherited security setting apply here. It is just
> local settings that are removed. Still, seems to be just wrong to me.
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Suspicious code in MacroImpl deleteObject
Posted by Oliver Zeigermann <ol...@gmail.com>.
Wouldn't it be possible to first delete the content and node
information and then delete permission and locking *directly* on the
store that contained the object? Without going through the helpers?
Oliver
On Tue, 19 Oct 2004 13:12:06 -0400, Jim Myers <ji...@verizon.net> wrote:
> Oliver,
>
> Not sure it applies here, but I remember looking around one time and
> discovering that removing permissions ends up checking to see if the object
> exists, so if they aren't removed before the object is deleted, you get
> errors. revokePermission() has a call to checkCredentials(token, object,
> ...) in it. For slide 1, I think we kludged and silently caught the
> ObjectNotFoundException caused by Macro.delete().
>
> With a quick look in MacroImpl, I'm don't see any way that a security
> setting on the node being delted is getting checked either, but a fix will
> probably have to do more than just remove content and then the
> permissions...
>
> Jim
>
>
>
>
> ----- Original Message -----
> From: "Oliver Zeigermann" <ol...@gmail.com>
> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> Sent: Tuesday, October 19, 2004 11:32 AM
> Subject: Re: Suspicious code in MacroImpl deleteObject
>
> On Tue, 19 Oct 2004 16:44:36 +0200, Stefan Lützkendorf
> <lu...@apache.org> wrote:
> >
> > Versions are maintained at the version history resource I think. That
> > one of the things im bewildered again and again (:-)
> > If you put a resource under version control and check it in some times,
> > you will not found any aditional revisiondescriptor at the resource but
> > at the history resource. So I think (webdav) versions are NOT removed.
> > (Multiple revisions I have ever observerd when removing the history
> > resource, i.e. the collection where the versions are stored) (Thats why
> > think the webdav versioning and the slide versioning are designed under
> > different views, and something could be improved we only want to support
> > webdav)
>
> Right, forgot about that...
>
> > The other point looks weired too. First locka and permissions are
> > removed, and than content and the node are removed. The checks in
> > ContentImpl.remove and StructureImpl.remove seem to be made effectless.
> > But why we dont observe strange security violations?
>
> I guess because inherited security setting apply here. It is just
> local settings that are removed. Still, seems to be just wrong to me.
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Suspicious code in MacroImpl deleteObject
Posted by Jim Myers <ji...@verizon.net>.
Oliver,
Not sure it applies here, but I remember looking around one time and
discovering that removing permissions ends up checking to see if the object
exists, so if they aren't removed before the object is deleted, you get
errors. revokePermission() has a call to checkCredentials(token, object,
...) in it. For slide 1, I think we kludged and silently caught the
ObjectNotFoundException caused by Macro.delete().
With a quick look in MacroImpl, I'm don't see any way that a security
setting on the node being delted is getting checked either, but a fix will
probably have to do more than just remove content and then the
permissions...
Jim
----- Original Message -----
From: "Oliver Zeigermann" <ol...@gmail.com>
To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
Sent: Tuesday, October 19, 2004 11:32 AM
Subject: Re: Suspicious code in MacroImpl deleteObject
On Tue, 19 Oct 2004 16:44:36 +0200, Stefan Lützkendorf
<lu...@apache.org> wrote:
>
> Versions are maintained at the version history resource I think. That
> one of the things im bewildered again and again (:-)
> If you put a resource under version control and check it in some times,
> you will not found any aditional revisiondescriptor at the resource but
> at the history resource. So I think (webdav) versions are NOT removed.
> (Multiple revisions I have ever observerd when removing the history
> resource, i.e. the collection where the versions are stored) (Thats why
> think the webdav versioning and the slide versioning are designed under
> different views, and something could be improved we only want to support
> webdav)
Right, forgot about that...
> The other point looks weired too. First locka and permissions are
> removed, and than content and the node are removed. The checks in
> ContentImpl.remove and StructureImpl.remove seem to be made effectless.
> But why we dont observe strange security violations?
I guess because inherited security setting apply here. It is just
local settings that are removed. Still, seems to be just wrong to me.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Suspicious code in MacroImpl deleteObject
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Tue, 19 Oct 2004 16:44:36 +0200, Stefan Lützkendorf
<lu...@apache.org> wrote:
>
> Versions are maintained at the version history resource I think. That
> one of the things im bewildered again and again (:-)
> If you put a resource under version control and check it in some times,
> you will not found any aditional revisiondescriptor at the resource but
> at the history resource. So I think (webdav) versions are NOT removed.
> (Multiple revisions I have ever observerd when removing the history
> resource, i.e. the collection where the versions are stored) (Thats why
> think the webdav versioning and the slide versioning are designed under
> different views, and something could be improved we only want to support
> webdav)
Right, forgot about that...
> The other point looks weired too. First locka and permissions are
> removed, and than content and the node are removed. The checks in
> ContentImpl.remove and StructureImpl.remove seem to be made effectless.
> But why we dont observe strange security violations?
I guess because inherited security setting apply here. It is just
local settings that are removed. Still, seems to be just wrong to me.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Suspicious code in MacroImpl deleteObject
Posted by Stefan Lützkendorf <lu...@apache.org>.
Versions are maintained at the version history resource I think. That
one of the things im bewildered again and again (:-)
If you put a resource under version control and check it in some times,
you will not found any aditional revisiondescriptor at the resource but
at the history resource. So I think (webdav) versions are NOT removed.
(Multiple revisions I have ever observerd when removing the history
resource, i.e. the collection where the versions are stored) (Thats why
think the webdav versioning and the slide versioning are designed under
different views, and something could be improved we only want to support
webdav)
The other point looks weired too. First locka and permissions are
removed, and than content and the node are removed. The checks in
ContentImpl.remove and StructureImpl.remove seem to be made effectless.
But why we dont observe strange security violations?
Stefan
Oliver Zeigermann wrote:
> While working on the MacroStore implementation I discovered code in
> MacroImpl deleteObject that looks suspicious to me. It revokes all
> permissions and locks before trying to delete something and
> additionally seems to remove all versions as well.
>
> Could someone confirm this is indeed the case and if so, why?
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org