[jira] [Commented] (ACCUMULO-2806) Accumulo init should ensure wals and tables are not world readable
[
https://issues.apache.org/jira/browse/ACCUMULO-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15883464#comment-15883464
]
Sean Busbey commented on ACCUMULO-2806:
---
AFAIK it just fell to our common handling of "ops problem, but there's a
workaround".
> Accumulo init should ensure wals and tables are not world readable
> --
>
> Key: ACCUMULO-2806
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2806
> Project: Accumulo
> Issue Type: Bug
>Affects Versions: 1.5.0, 1.5.1, 1.6.0
>Reporter: Sean Busbey
>Assignee: Michael Miller
>Priority: Critical
> Fix For: 1.8.2, 2.0.0
>
>
> Just did an init on a new 1.6.1-SNAP cluster, and noticed the following
> permissions:
> {noformat}
> dfs -ls /
> Found 4 items
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:48 /accumulo
> drwxr-xr-x - hdfs supergroup 0 2014-05-14 08:10 /jobtracker
> drwxrwxrwx - hdfs supergroup 0 2014-05-14 08:10 /tmp
> drwxr-xr-x - hdfs supergroup 0 2014-05-14 09:48 /user
> -bash-4.1$ hdfs dfs -ls /accumulo
> Found 3 items
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:55
> /accumulo/instance_id
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:55
> /accumulo/tables
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:55
> /accumulo/version
> {noformat}
> I previously set up /accumulo as 755, under the understanding that clients
> need access to /accumulo/instance_id
> things to fix
> # make init chmod tables and wals to 700, as a defensive measure to avoid
> data leaks
> # maybe also make sure if the trash is enabled that our user directory is
> also not world readable
> # If clients don't need access to instance_id, include a check that the data
> dir is not world readable
> Workaround: manually change permissions after init
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
Accumulo-Pull-Requests - Build # 659 - Fixed
The Apache Jenkins build system has built Accumulo-Pull-Requests (build #659) Status: Fixed Check console output at https://builds.apache.org/job/Accumulo-Pull-Requests/659/ to view the results.
[jira] [Updated] (ACCUMULO-4409) Create a custom log4j AccumuloMonitorAppender
[ https://issues.apache.org/jira/browse/ACCUMULO-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4409: Labels: release_notes (was: ) > Create a custom log4j AccumuloMonitorAppender > - > > Key: ACCUMULO-4409 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4409 > Project: Accumulo > Issue Type: Sub-task >Reporter: Christopher Tubbs >Assignee: Christopher Tubbs > Labels: release_notes > Fix For: 2.0.0 > > > The current AsyncSocketAppender was an improvement over the older log4j > configuration options, but it did not fully satisfy the description in > ACCUMULO-2343. > What we really need is an appender which can be managed by configuration > alone, without using code to reload it with new system properties when the > location of the monitor changes. > So, rather than having a ZK watcher reload the log4j system, the appender > itself should internally detect the relocation of the monitor and adjust its > behavior accordingly. That way, the configuration files do not need to refer > to system properties for the hostname/port of the monitor, and there is no > need to reload the log4j logging when things change. > This will allow us to remove more custom log4j code, which gets us closer to > users having the ability to use another implementation for the slf4j API > (though this feature of logging to the monitor might not be available for > other slf4j implementations, unless they support using log4j appenders). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (ACCUMULO-2806) Accumulo init should ensure wals and tables are not world readable
[
https://issues.apache.org/jira/browse/ACCUMULO-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Miller reassigned ACCUMULO-2806:
Assignee: Michael Miller
> Accumulo init should ensure wals and tables are not world readable
> --
>
> Key: ACCUMULO-2806
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2806
> Project: Accumulo
> Issue Type: Bug
>Affects Versions: 1.5.0, 1.5.1, 1.6.0
>Reporter: Sean Busbey
>Assignee: Michael Miller
>Priority: Critical
> Fix For: 1.8.2, 2.0.0
>
>
> Just did an init on a new 1.6.1-SNAP cluster, and noticed the following
> permissions:
> {noformat}
> dfs -ls /
> Found 4 items
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:48 /accumulo
> drwxr-xr-x - hdfs supergroup 0 2014-05-14 08:10 /jobtracker
> drwxrwxrwx - hdfs supergroup 0 2014-05-14 08:10 /tmp
> drwxr-xr-x - hdfs supergroup 0 2014-05-14 09:48 /user
> -bash-4.1$ hdfs dfs -ls /accumulo
> Found 3 items
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:55
> /accumulo/instance_id
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:55
> /accumulo/tables
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:55
> /accumulo/version
> {noformat}
> I previously set up /accumulo as 755, under the understanding that clients
> need access to /accumulo/instance_id
> things to fix
> # make init chmod tables and wals to 700, as a defensive measure to avoid
> data leaks
> # maybe also make sure if the trash is enabled that our user directory is
> also not world readable
> # If clients don't need access to instance_id, include a check that the data
> dir is not world readable
> Workaround: manually change permissions after init
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
Accumulo-Pull-Requests - Build # 658 - Unstable
The Apache Jenkins build system has built Accumulo-Pull-Requests (build #658) Status: Unstable Check console output at https://builds.apache.org/job/Accumulo-Pull-Requests/658/ to view the results.
[jira] [Updated] (ACCUMULO-4589) Wikisearch Search with no results throws Error
[
https://issues.apache.org/jira/browse/ACCUMULO-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Miller updated ACCUMULO-4589:
-
Summary: Wikisearch Search with no results throws Error (was: Search with
no results throws Error)
> Wikisearch Search with no results throws Error
> --
>
> Key: ACCUMULO-4589
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4589
> Project: Accumulo
> Issue Type: Bug
> Components: wikisearch
>Affects Versions: 1.8.0
>Reporter: Michael Miller
>Priority: Minor
>
> When performing a fielded search, i.e. TEXT == 'blah', for a term that is not
> indexed an unhelpful exception is thrown:
> {code}
> org.jboss.resteasy.spi.UnhandledException:
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>
> org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345)
>
> org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:341)
>
> org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321)
>
> org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214)
>
> org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190)
>
> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534)
>
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-2806) Accumulo init should ensure wals and tables are not world readable
[
https://issues.apache.org/jira/browse/ACCUMULO-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15883017#comment-15883017
]
Michael Miller commented on ACCUMULO-2806:
--
When this was created, it seemed to be fairly important but was never
implemented. I looked into this a bit and seems like a fairly simple fix to by
adding a mkdirs() method to our VolumeManager that accepts permissions as a
parameter. Did this just get lost or was there a larger functional issue with
changing the permissions of Accumulo directories?
> Accumulo init should ensure wals and tables are not world readable
> --
>
> Key: ACCUMULO-2806
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2806
> Project: Accumulo
> Issue Type: Bug
>Affects Versions: 1.5.0, 1.5.1, 1.6.0
>Reporter: Sean Busbey
>Priority: Critical
> Fix For: 1.8.2, 2.0.0
>
>
> Just did an init on a new 1.6.1-SNAP cluster, and noticed the following
> permissions:
> {noformat}
> dfs -ls /
> Found 4 items
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:48 /accumulo
> drwxr-xr-x - hdfs supergroup 0 2014-05-14 08:10 /jobtracker
> drwxrwxrwx - hdfs supergroup 0 2014-05-14 08:10 /tmp
> drwxr-xr-x - hdfs supergroup 0 2014-05-14 09:48 /user
> -bash-4.1$ hdfs dfs -ls /accumulo
> Found 3 items
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:55
> /accumulo/instance_id
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:55
> /accumulo/tables
> drwxr-xr-x - accumulo supergroup 0 2014-05-14 09:55
> /accumulo/version
> {noformat}
> I previously set up /accumulo as 755, under the understanding that clients
> need access to /accumulo/instance_id
> things to fix
> # make init chmod tables and wals to 700, as a defensive measure to avoid
> data leaks
> # maybe also make sure if the trash is enabled that our user directory is
> also not world readable
> # If clients don't need access to instance_id, include a check that the data
> dir is not world readable
> Workaround: manually change permissions after init
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
