[
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 8:01 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}
{panel:title=5}
There appears to be a bug here:
{code:java|title=AbstractBTreePartition.rename(RenameOperationContext)
line(2096)}
if ( renameContext.getEntry() != null )
{
Entry modifiedEntry = renameContext.getModifiedEntry();
rename( oldDn, newRdn, deleteOldRdn, modifiedEntry );
}
{code}
It seems wrong to check if {{getEntry()}} is not null then use
{{getModifiedEntry()}} to pass to rename. That is, unless there is some
implicit guarantee that the presense of entry ensures a modified entry is also
present.
{panel}
was (Author: [email protected]):
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}
> 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)
