curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "josh gruenberg (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CURATOR-489) CreateMode.doProtected uses null protectedId when applied via AsyncCreateBuilderImpl
Date Tue, 04 Dec 2018 18:03:00 GMT
josh gruenberg created CURATOR-489:
--------------------------------------

             Summary: CreateMode.doProtected uses null protectedId when applied via AsyncCreateBuilderImpl
                 Key: CURATOR-489
                 URL: https://issues.apache.org/jira/browse/CURATOR-489
             Project: Apache Curator
          Issue Type: Bug
    Affects Versions: 4.0.1
            Reporter: josh gruenberg
            Assignee: Jordan Zimmerman


When trying to apply "protection" to an async node-creation with
 {{CreateOption.doProtected}}, the protected is undermined because the node is created with
{{protectionId = null}}.

The {{AsyncCreateBuilderImpl}} does pass {{doProtected = true}} to the {{CreateBuilderImpl}}
constructor. However, this constructor (incorrectly?) assigns {{protectedId = null}}, resulting
in a node-prefix of {{_c_null-}} (because {{getProtectedPrefix}} does not validate that the
provided {{protectedId}} is non-null). This entirely undermines the effectiveness of the protection.

{code:java}
    public CreateBuilderImpl(CuratorFrameworkImpl client, CreateMode createMode, Backgrounding
backgrounding, boolean createParentsIfNeeded, boolean createParentsAsContainers, boolean doProtected,
boolean compress, boolean setDataIfExists, List<ACL> aclList, Stat storingStat, long
ttl)
    {
        this.client = client;
        this.createMode = createMode;
        this.backgrounding = backgrounding;
        this.createParentsIfNeeded = createParentsIfNeeded;
        this.createParentsAsContainers = createParentsAsContainers;
        this.doProtected = doProtected;
        this.compress = compress;
        this.setDataIfExists = setDataIfExists;
        protectedId = null;                     // *** incorrect if doProtected?! ***
        this.acling = new ACLing(client.getAclProvider(), aclList);
        this.storingStat = storingStat;
        this.ttl = ttl;
    }
{code}
It looks to me as if that constructor should be assigning {{protectedId}} if {{doProtected}}
is true.

I wonder if the {{doProtected}} field should just be eliminated in favor a method that checks
{{protectedId != null}}, to avoid this redundant encoding of intent?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message