Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Date: Fri, 9 Oct 2015 19:47:07 +0000 (UTC)
From: "lucas theisen (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Message-ID: <JIRA.12711698.1398950478000.1945.1444420027772@Atlassian.JIRA>
In-Reply-To: <JIRA.12711698.1398950478000@Atlassian.JIRA>
References: <JIRA.12711698.1398950478000@Atlassian.JIRA>
 <JIRA.12711698.1398950478075@arcas>
Subject: [jira] [Comment Edited] (DIRSERVER-1974) Rename Operation Issue -
 ApacheDS
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DIRSERVER-1974?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14951024#comment-14951024 ]=20

lucas theisen edited comment on DIRSERVER-1974 at 10/9/15 7:46 PM:
-------------------------------------------------------------------

Notes:
{panel:title=3D1}
{code:java|title=3DAciAuthorizationInterceptor (line 1149)}
    public void rename( RenameOperationContext renameContext ) throws LdapE=
xception
    {
        Dn oldName =3D renameContext.getDn();
        Entry originalEntry =3D null;

        if ( renameContext.getEntry() !=3D null )
        {
            originalEntry =3D ( ( ClonedServerEntry ) renameContext.getEntr=
y() ).getOriginalEntry();
        }

        LdapPrincipal principal =3D renameContext.getSession().getEffective=
Principal();
        Dn principalDn =3D principal.getDn();
        Dn newName =3D renameContext.getNewDn();

        // bypass authz code if we are disabled
        if ( !directoryService.isAccessControlEnabled() )
        {
            next( renameContext );
            return;
        }
{code}
The bypass check in the above code should probably be the first code in thi=
s method.
{panel}
{panel:title=3D2}
It appears the actual modification to the entry (setting the new DN value) =
is done in {{SchemaInterceptor}}.  I thought schema interceptor was just fo=
r validating the upcoming change, not actually making any modification.  Bu=
t I don't really know for sure...

Further investigation shows that {{AbstractChangeOperationContext}} has a m=
ember called {{modifiedEntry}} which is the entry that will be stored.  So =
modification to the entry returned by {{getEntry}} (the one that {{SchemaIn=
terceptor}} modifies) would not actually have any persistent effect.  Thoug=
h still clueless as to why soooo many copies of the entry.
{panel}
{panel:title=3D3}
More confusion...  {{AbstractOperationContext}} implements {{OperationConte=
xt}}.  {{OperationContext}} has javadoc stating that {{getEntry}} will retu=
rn a {{ClonedServerEntry}} which is guaranteed to contain an immutable copy=
 of the original entry.  But {{AbstractOperationContext}} adds a member {{o=
riginalEntry}} as well.  Why?  Are they the same?  Could {{AbstractOperatio=
nContext.getOriginalEntry()}} just {{return getEntry().getOriginalEntry()}}=
 instead of maintaining its own copy?
{panel}
{panel:title=3D4}
It seems like {{SubentryInterceptor}} should be using {{Entry entry =3D ( (=
 ClonedServerEntry ) renameContext.getEntry() ).getOriginalEntry()}} instea=
d of {{Entry entry =3D ( ( ClonedServerEntry ) renameContext.getEntry() ).g=
etClonedEntry()}}.  As the cloned entry may have been modified before reach=
ing this point... Though i guess that could have been on purpose...  Either=
 way it seems dangerous as the modified entry is what will actually get sto=
red and the original entry is what it is before modification...  The entry =
itself is just ephemeral...
{panel}


was (Author: ltheisen@mitre.org):
Notes:
{panel:title=3D1}
{code:java|title=3DAciAuthorizationInterceptor (line 1149)}
    public void rename( RenameOperationContext renameContext ) throws LdapE=
xception
    {
        Dn oldName =3D renameContext.getDn();
        Entry originalEntry =3D null;

        if ( renameContext.getEntry() !=3D null )
        {
            originalEntry =3D ( ( ClonedServerEntry ) renameContext.getEntr=
y() ).getOriginalEntry();
        }

        LdapPrincipal principal =3D renameContext.getSession().getEffective=
Principal();
        Dn principalDn =3D principal.getDn();
        Dn newName =3D renameContext.getNewDn();

        // bypass authz code if we are disabled
        if ( !directoryService.isAccessControlEnabled() )
        {
            next( renameContext );
            return;
        }
{code}
The bypass check in the above code should probably be the first code in thi=
s method.
{panel}
{panel:title=3D2}
It appears the actual modification to the entry (setting the new DN value) =
is done in {{SchemaInterceptor}}.  I thought schema interceptor was just fo=
r validating the upcoming change, not actually making any modification.  Bu=
t I don't really know for sure...

Further investigation shows that {{AbstractChangeOperationContext}} has a m=
ember called {{modifiedEntry}} which is the entry that will be stored.  So =
modification to the entry returned by {{getEntry}} (the one that {{SchemaIn=
terceptor}} modifies) would not actually have any persistent effect.  Thoug=
h still clueless as to why soooo many copies of the entry.
{panel}
{panel:title=3D3}
More confusion...  {{AbstractOperationContext}} implements {{OperationConte=
xt}}.  {{OperationContext}} has javadoc stating that {{getEntry}} will retu=
rn a {{ClonedServerEntry}} which is guaranteed to contain an immutable copy=
 of the original entry.  But {{AbstractOperationContext}} adds a member {{o=
riginalEntry}} as well.  Why?  Are they the same?  Could {{AbstractOperatio=
nContext.getOriginalEntry()}} just {{return getEntry().getOriginalEntry()}}=
 instead of maintaining its own copy?
{panel}

> Rename Operation Issue - ApacheDS
> ---------------------------------
>
>                 Key: DIRSERVER-1974
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1974
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: ldap
>    Affects Versions: 2.0.0-M15
>         Environment: Window server 2008 R2
>            Reporter: Mohd Usman
>            Priority: Blocker
>              Labels: build, features, patch
>         Attachments: ApacheDSSchemaBrowser.png, CNAttributeInSchema.png, =
PostRename.png, PreRename.png, SchemaViewerLDAPAdminTool.png
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Whenever we perform Rename operation on an object entry (let=E2=80=99s sa=
y Person object), the person gets renamed successfully but the issue is tha=
t the old value of the person object still remains.
> The =E2=80=98cn=E2=80=99 attribute contains two values now - old value an=
d also the new value.
> =20
> Example:
> I have created a person object with DN "cn=3Dperson,ou=3DApache,dc=3Dexam=
ple,dc=3Dcom" and I want to rename this entry to "cn=3Dperson_Rename,ou=3DA=
pache,dc=3Dexample,dc=3Dcom".
> The rename operation executes successfully and the person is renamed to "=
cn=3Dperson_Rename,ou=3DApache,dc=3Dexample,dc=3Dcom".=20
> But, the =E2=80=98cn=E2=80=99 attribute now contains=20
> =E2=80=9Cperson=E2=80=9D
> =E2=80=9Cperson_Rename=E2=80=9D.
> When verified the schema, =E2=80=98cn=E2=80=99 attribute show as =E2=80=
=98single valued=E2=80=99 but after performing the rename operation =E2=80=
=93 the =E2=80=98cn=E2=80=99 becomes =E2=80=98multi-valued=E2=80=99 and con=
tains two values.
> This an issue with Apache directory which needs to be resolved. Also find=
 the screenshots attached for your reference. Please look into the same.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)