accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4415) Tracer requires instance.secret
Date Fri, 19 Aug 2016 16:46:20 GMT


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:
>             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(
> 		at org.apache.zookeeper.KeeperException.create(
> 		at org.apache.zookeeper.ZooKeeper.create(
> 		at org.apache.accumulo.fate.zookeeper.ZooUtil.putEphemeralSequential(
> 		at org.apache.accumulo.fate.zookeeper.ZooReaderWriter.putEphemeralSequential(
> 		at org.apache.accumulo.tracer.TraceServer.registerInZooKeeper(
> 		at org.apache.accumulo.tracer.TraceServer.<init>(
> 		at org.apache.accumulo.tracer.TraceServer.main(
> 		at org.apache.accumulo.tracer.TracerExecutable.execute(
> 		at org.apache.accumulo.start.Main$
> 		at
> {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

View raw message