directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lucas theisen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DIRSERVER-1974) Rename Operation Issue - ApacheDS
Date Fri, 09 Oct 2015 19:47:07 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14951024#comment-14951024
] 

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

Notes:
{panel:title=1}
{code:java|title=AciAuthorizationInterceptor (line 1149)}
    public void rename( RenameOperationContext renameContext ) throws LdapException
    {
        Dn oldName = renameContext.getDn();
        Entry originalEntry = null;

        if ( renameContext.getEntry() != null )
        {
            originalEntry = ( ( ClonedServerEntry ) renameContext.getEntry() ).getOriginalEntry();
        }

        LdapPrincipal principal = renameContext.getSession().getEffectivePrincipal();
        Dn principalDn = principal.getDn();
        Dn newName = 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 this method.
{panel}
{panel:title=2}
It appears the actual modification to the entry (setting the new DN value) is done in {{SchemaInterceptor}}.
 I thought schema interceptor was just for validating the upcoming change, not actually making
any modification.  But I don't really know for sure...

Further investigation shows that {{AbstractChangeOperationContext}} has a member called {{modifiedEntry}}
which is the entry that will be stored.  So modification to the entry returned by {{getEntry}}
(the one that {{SchemaInterceptor}} modifies) would not actually have any persistent effect.
 Though still clueless as to why soooo many copies of the entry.
{panel}
{panel:title=3}
More confusion...  {{AbstractOperationContext}} implements {{OperationContext}}.  {{OperationContext}}
has javadoc stating that {{getEntry}} will return a {{ClonedServerEntry}} which is guaranteed
to contain an immutable copy of the original entry.  But {{AbstractOperationContext}} adds
a member {{originalEntry}} as well.  Why?  Are they the same?  Could {{AbstractOperationContext.getOriginalEntry()}}
just {{return getEntry().getOriginalEntry()}} instead of maintaining its own copy?
{panel}
{panel:title=4}
It seems like {{SubentryInterceptor}} should be using {{Entry entry = ( ( ClonedServerEntry
) renameContext.getEntry() ).getOriginalEntry()}} instead of {{Entry entry = ( ( ClonedServerEntry
) renameContext.getEntry() ).getClonedEntry()}}.  As the cloned entry may have been modified
before reaching 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 stored 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=1}
{code:java|title=AciAuthorizationInterceptor (line 1149)}
    public void rename( RenameOperationContext renameContext ) throws LdapException
    {
        Dn oldName = renameContext.getDn();
        Entry originalEntry = null;

        if ( renameContext.getEntry() != null )
        {
            originalEntry = ( ( ClonedServerEntry ) renameContext.getEntry() ).getOriginalEntry();
        }

        LdapPrincipal principal = renameContext.getSession().getEffectivePrincipal();
        Dn principalDn = principal.getDn();
        Dn newName = 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 this method.
{panel}
{panel:title=2}
It appears the actual modification to the entry (setting the new DN value) is done in {{SchemaInterceptor}}.
 I thought schema interceptor was just for validating the upcoming change, not actually making
any modification.  But I don't really know for sure...

Further investigation shows that {{AbstractChangeOperationContext}} has a member called {{modifiedEntry}}
which is the entry that will be stored.  So modification to the entry returned by {{getEntry}}
(the one that {{SchemaInterceptor}} modifies) would not actually have any persistent effect.
 Though still clueless as to why soooo many copies of the entry.
{panel}
{panel:title=3}
More confusion...  {{AbstractOperationContext}} implements {{OperationContext}}.  {{OperationContext}}
has javadoc stating that {{getEntry}} will return a {{ClonedServerEntry}} which is guaranteed
to contain an immutable copy of the original entry.  But {{AbstractOperationContext}} adds
a member {{originalEntry}} as well.  Why?  Are they the same?  Could {{AbstractOperationContext.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’s say Person object),
the person gets renamed successfully but the issue is that the old value of the person object
still remains.
> The ‘cn’ attribute contains two values now - old value and also the new value.
>  
> Example:
> I have created a person object with DN "cn=person,ou=Apache,dc=example,dc=com" and I
want to rename this entry to "cn=person_Rename,ou=Apache,dc=example,dc=com".
> The rename operation executes successfully and the person is renamed to "cn=person_Rename,ou=Apache,dc=example,dc=com".

> But, the ‘cn’ attribute now contains 
> “person”
> “person_Rename”.
> When verified the schema, ‘cn’ attribute show as ‘single valued’ but after performing
the rename operation – the ‘cn’ becomes ‘multi-valued’ and contains 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)

Mime
View raw message