Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-729

Issue when creating an entry copying an existing one

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.5.3
    • Fix Version/s: None
    • Component/s: studio-ldapbrowser
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Pierre-Arnaud Marcelot added a comment -

        I think you're right.
        We're probably copy/pasting the whole entry without removing operational attributes.
        Definitely a bug...

        Show
        Pierre-Arnaud Marcelot added a comment - I think you're right. We're probably copy/pasting the whole entry without removing operational attributes. Definitely a bug...
        Hide
        Kiran Ayyagari added a comment -

        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)

        Show
        Kiran Ayyagari added a comment - 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)
        Hide
        Emmanuel Lecharny added a comment -

        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.

        Show
        Emmanuel Lecharny added a comment - 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.
        Hide
        Kiran Ayyagari added a comment -

        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.

        Show
        Kiran Ayyagari added a comment - 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.
        Hide
        Emmanuel Lecharny added a comment -

        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.

        Show
        Emmanuel Lecharny added a comment - 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.
        Hide
        Stefan Seelmann added a comment -

        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.

        Show
        Stefan Seelmann added a comment - 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.
        Hide
        Emmanuel Lecharny added a comment -

        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)

        Show
        Emmanuel Lecharny added a comment - 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)
        Hide
        Pierre-Arnaud Marcelot added a comment -

        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.

        Show
        Pierre-Arnaud Marcelot added a comment - 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.

          People

          • Assignee:
            Pierre-Arnaud Marcelot
            Reporter:
            Emmanuel Lecharny
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development