accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dylan Hutchison <dhutc...@cs.washington.edu>
Subject Re: Custom Java SecurityManager permissions
Date Tue, 16 Aug 2016 01:13:19 GMT
Maybe related to ACCUMULO-1188
<https://issues.apache.org/jira/browse/ACCUMULO-1188>?

On Mon, Aug 15, 2016 at 10:09 AM, Josh Elser <josh.elser@gmail.com> wrote:

> +1 from me.
>
> IIRC, they used to be something to try to guard against user JARs
> (containing iterators) doing something malicious, but obviously they
> haven't been kept up given the lack of documentation. I am not sure what
> all is possible to say whether or not it's a completely security solution
> too.
>
> I think without context on what they do, how they work, etc, they can be
> removed.
>
>
> Christopher wrote:
>
>> Bump. Anybody have any thoughts on these? I'm inclined to rip out the
>> custom permissions here. I don't think they're actually adding any
>> security, and we're not documenting them in any overall security model. As
>> is, they look like remnants of an early, incomplete attempt to apply the
>> Java security system to our code, but they don't look like they are
>> offering anything in the current implementation to actually improve the
>> security.
>>
>> On Thu, Aug 11, 2016 at 9:46 PM Christopher<ctubbsii@apache.org>  wrote:
>>
>> I found 7 references in our code (master branch, probably same in others)
>>> to the java SecurityManager.checkPermissions, each with custom
>>> permissions
>>> we've created (3 in core, 1 in fate, 3 in server-base).
>>>
>>> There is no documentation for these, and I don't really know what these
>>> are actually trying to protect against.
>>>
>>> Do these custom permissions have any actual purpose? What value are these
>>> adding?
>>>
>>> Do we have an overall security model which we can check these
>>> implementations against? Or to identify where we are missing checks which
>>> should be there? Do we really need to create custom permissions, vs. some
>>> standardized ones?
>>>
>>>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message