[
https://issues.apache.org/jira/browse/ACCUMULO-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428429#comment-15428429
]
Christopher Tubbs commented on ACCUMULO-4415:
---------------------------------------------
bq. o.O what would be comprised in this project? The SpanReceiver which can
pull Accumulo Trace server locations from ZK and send the spans to it? This
seems like an orthogonal discussion to the permissions on registration of
Accumulo Trace Servers in ZK.
I was thinking the SpanReceiver *AND* the Tracer server would be part of that
project. The Tracer server is essentially an ingest client for Accumulo...
that's why it has it's own username/password. It's not an "Accumulo server" in
the same sense as Master/TServer/GC are, but it does mimic the service
advertisement behavior of those.
It wouldn't make much sense for the SpanReceiver to be separate, and the Tracer
to stay with Accumulo. Because that would basically mean Accumulo is providing
a separate receiving service for one particular kind of message from one
particular kind of library... but not any others. It'd be like if mysql had a
special service listening constantly for rsyslog messages, whether or not you
had rsyslog configured to send logs to mysql. That doesn't make a lot of sense
to me.
bq. I think we should stick to figuring out whether or not Spans (comprised of
a description, timeline annotations, and key-value annotations) might contain
sensitive information, and thus, if we need to control the users which are
allowed to register in {{/tracers}}.
That's probably a good first step. The easiest immediate fix is to have
ChangeSecret update this directory, too... but I'm concerned that sets us on a
bad path. The next easiest is to make the SpanReceiver code authenticate to the
tracer with a shared secret to prevent leakage. This secret (or another one)
can also be used to protect the service advertisement area, to prevent DoS of
the SpanReceiver.
> Tracer requires instance.secret
> -------------------------------
>
> Key: ACCUMULO-4415
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4415
> Project: Accumulo
> Issue Type: Bug
> Components: trace
> Reporter: Christopher Tubbs
> Fix For: 1.8.1
>
>
> Tracer incorrectly uses instance.secret for its /tracers area in ZooKeeper.
> The tracer does not use the Accumulo system credentials, and instead uses a
> specific tracer username and password. It should also not use the
> instance.secret (which is for the system credentials).
> A side effect of this bug is that ChangeSecret does not update the /tracers
> ACLs in ZooKeeper, preventing the tracer from working entirely after the
> instance.secret is changed.
> The following error will be seen in the monitor after the ChangeSecret tool
> is run.
> {code}
> Thread 'tracer' died.
> org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode =
> NoAuth for /tracers/trace-
> at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:113)
> at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
> at
> org.apache.accumulo.fate.zookeeper.ZooUtil.putEphemeralSequential(ZooUtil.java:464)
> at
> org.apache.accumulo.fate.zookeeper.ZooReaderWriter.putEphemeralSequential(ZooReaderWriter.java:99)
> at
> org.apache.accumulo.tracer.TraceServer.registerInZooKeeper(TraceServer.java:318)
> at
> org.apache.accumulo.tracer.TraceServer.<init>(TraceServer.java:255)
> at
> org.apache.accumulo.tracer.TraceServer.main(TraceServer.java:360)
> at
> org.apache.accumulo.tracer.TracerExecutable.execute(TracerExecutable.java:33)
> at org.apache.accumulo.start.Main$1.run(Main.java:120)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This affects at least the current 1.8 branch (1.8.0-SNAPSHOT), but I haven't
> checked earlier versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
