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)
