You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2011/03/15 10:19:29 UTC
[jira] Created: (DIRSTUDIO-729) Issue when creating an entry
copying an existing one
Issue when creating an entry copying an existing one
----------------------------------------------------
Key: DIRSTUDIO-729
URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
Project: Directory Studio
Issue Type: Bug
Components: studio-ldapbrowser
Affects Versions: 1.5.3
Reporter: Emmanuel Lecharny
Fix For: 2.0.0
When creating a new entry, copying it from an existing entry, we get an error :
[LDAP: error code 19 - entryCSN : no user modification allowed]
The connection has been set to require the OperationalAttributes to be read when fetching entries. I'm wondering if the problem is not a side effect : the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSTUDIO-729) Issue when creating an entry
copying an existing one
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006896#comment-13006896 ]
Emmanuel Lecharny commented on DIRSTUDIO-729:
---------------------------------------------
To be more specific, not *all* the OpAttrs are modifiable by the user. Most of them aren't : see RFC 4512, par 3.4.
The EntryCSN OpAttr for instance has no reason to be injected by a user - even the administrator -, except by the Syncrepl user. That means we have to deal with this kind of attribute carefully.
It raises another aspect : if we forbid the admin to inject entries with such attributes into the server, then do we correctly administrate those OpAttrs when we proceed operations *inside* the server ? (keep in mind that we switch to the admin user in such case).
Not really simple.
Anyway, from the Studio POV, copying the OpAttrs when creating a new entry seems to be the wrong thing to do, regardless of how the servers handle such OpAttrs.
> Issue when creating an entry copying an existing one
> ----------------------------------------------------
>
> Key: DIRSTUDIO-729
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> When creating a new entry, copying it from an existing entry, we get an error :
> [LDAP: error code 19 - entryCSN : no user modification allowed]
> The connection has been set to require the OperationalAttributes to be read when fetching entries. I'm wondering if the problem is not a side effect : the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSTUDIO-729) Issue when creating an entry
copying an existing one
Posted by "Kiran Ayyagari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006868#comment-13006868 ]
Kiran Ayyagari commented on DIRSTUDIO-729:
------------------------------------------
It is perfectly valid when performed by an admin user. I think the OperationalAttributeInterceptor is behaving odd in the case of entryCSN which needs to be checked. Having said that, we do need to add few more checks to prevent addition of duplicate entryUUID and entryCSN values (some presence checks on the corresponding indexes in the Partition's add operation will prevent this from happening)
> Issue when creating an entry copying an existing one
> ----------------------------------------------------
>
> Key: DIRSTUDIO-729
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> When creating a new entry, copying it from an existing entry, we get an error :
> [LDAP: error code 19 - entryCSN : no user modification allowed]
> The connection has been set to require the OperationalAttributes to be read when fetching entries. I'm wondering if the problem is not a side effect : the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DIRSTUDIO-729) Issue when creating an entry
copying an existing one
Posted by "Pierre-Arnaud Marcelot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre-Arnaud Marcelot resolved DIRSTUDIO-729.
----------------------------------------------
Resolution: Cannot Reproduce
Fix Version/s: (was: 2.0.0)
Assignee: Pierre-Arnaud Marcelot
I'm unable to reproduce this issue with the latest trunk version of both ApacheDS and Apache Directory Studio.
All operational attributes, including 'entryCSN', are perfectly well removed in the duplication of the entry.
> Issue when creating an entry copying an existing one
> ----------------------------------------------------
>
> Key: DIRSTUDIO-729
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Assignee: Pierre-Arnaud Marcelot
>
> When creating a new entry, copying it from an existing entry, we get an error :
> [LDAP: error code 19 - entryCSN : no user modification allowed]
> The connection has been set to require the OperationalAttributes to be read when fetching entries. I'm wondering if the problem is not a side effect : the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSTUDIO-729) Issue when creating an entry
copying an existing one
Posted by "Kiran Ayyagari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006893#comment-13006893 ]
Kiran Ayyagari commented on DIRSTUDIO-729:
------------------------------------------
ah OpenLDAP, ok I see the issue now. May be studio should check(in this cases only) with the schema for OP attributes before sending them and open up entry editor/wizard if some ATs can't be updated by user.
> Issue when creating an entry copying an existing one
> ----------------------------------------------------
>
> Key: DIRSTUDIO-729
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> When creating a new entry, copying it from an existing entry, we get an error :
> [LDAP: error code 19 - entryCSN : no user modification allowed]
> The connection has been set to require the OperationalAttributes to be read when fetching entries. I'm wondering if the problem is not a side effect : the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSTUDIO-729) Issue when creating an entry
copying an existing one
Posted by "Pierre-Arnaud Marcelot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006854#comment-13006854 ]
Pierre-Arnaud Marcelot commented on DIRSTUDIO-729:
--------------------------------------------------
I think you're right.
We're probably copy/pasting the whole entry without removing operational attributes.
Definitely a bug...
> Issue when creating an entry copying an existing one
> ----------------------------------------------------
>
> Key: DIRSTUDIO-729
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> When creating a new entry, copying it from an existing entry, we get an error :
> [LDAP: error code 19 - entryCSN : no user modification allowed]
> The connection has been set to require the OperationalAttributes to be read when fetching entries. I'm wondering if the problem is not a side effect : the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSTUDIO-729) Issue when creating an entry
copying an existing one
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006870#comment-13006870 ]
Emmanuel Lecharny commented on DIRSTUDIO-729:
---------------------------------------------
AFAIR, Those AttributeTypes are meaningfull only on the server, there is no reason an admin could modify them or inject new ones. The replication process must handle them differently.
The problem is not exposed when using ApacheDS btw, I was trying to add an entry on an OpenLDAP server, btw.
> Issue when creating an entry copying an existing one
> ----------------------------------------------------
>
> Key: DIRSTUDIO-729
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> When creating a new entry, copying it from an existing entry, we get an error :
> [LDAP: error code 19 - entryCSN : no user modification allowed]
> The connection has been set to require the OperationalAttributes to be read when fetching entries. I'm wondering if the problem is not a side effect : the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSTUDIO-729) Issue when creating an entry
copying an existing one
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006904#comment-13006904 ]
Emmanuel Lecharny commented on DIRSTUDIO-729:
---------------------------------------------
Thanks Stefan for the heads-up.
I wrote a mail about the EntryCSN and EntryUUID OpAttrs a while back :
http://web.archiveorange.com/archive/v/DCLZ8UmAvYgfzVPFCyD8
EntryCSN is supposed to have the NO_USER_MODIFCATION flag.
It is declared this way in OpenLDAP (in servers/slapd/schema_prep.c):
{ "entryCSN", "( 1.3.6.1.4.1.4203.666.1.7 NAME 'entryCSN' "
"DESC 'change sequence number of the entry content' "
"EQUALITY CSNMatch "
"ORDERING CSNOrderingMatch "
"SYNTAX 1.3.6.1.4.1.4203.666.11.2.1{64} "
"SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )",
NULL, SLAP_AT_HIDE,
NULL, NULL,
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_entryCSN) },
(OpenLDAP 2.4.24)
> Issue when creating an entry copying an existing one
> ----------------------------------------------------
>
> Key: DIRSTUDIO-729
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> When creating a new entry, copying it from an existing entry, we get an error :
> [LDAP: error code 19 - entryCSN : no user modification allowed]
> The connection has been set to require the OperationalAttributes to be read when fetching entries. I'm wondering if the problem is not a side effect : the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSTUDIO-729) Issue when creating an entry
copying an existing one
Posted by "Stefan Seelmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006898#comment-13006898 ]
Stefan Seelmann commented on DIRSTUDIO-729:
-------------------------------------------
Operational attributes - to be more precise attributes with the NO_USER_MODIFICATION flag - are filtered when copying an entry or when using an existing entry as template in the 'new entry' wizard.
If I understand Emmanuel right only the entryCSN attribute is affected. I was able to reproduce this with OpenLDAP. The problem is that entryCSN isn't included in OpenLDAP's schema, there is an open bug at the OpenLDAP issue tracker: http://www.openldap.org/its/index.cgi/Development?id=5573.
So there is no change to find out that entryCSN isn't writeable. We can hard-code that attribute or add a configuration dialog to configure non-writeable attributes.
> Issue when creating an entry copying an existing one
> ----------------------------------------------------
>
> Key: DIRSTUDIO-729
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> When creating a new entry, copying it from an existing entry, we get an error :
> [LDAP: error code 19 - entryCSN : no user modification allowed]
> The connection has been set to require the OperationalAttributes to be read when fetching entries. I'm wondering if the problem is not a side effect : the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira