stanbol-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <r...@apache.org>
Subject Re: [POLL] make "-no-security" the default
Date Fri, 05 Apr 2013 20:22:31 GMT
Hi Sergio,


> Stanbol is a a set of RESTful components for semantic content management.
> Therefore, using it I'd expect whatever security it could be provided,
> should be something optional on top of those components; i.e., enabling
> security should not affect the behaviour.
>

What do you mean by not affecting the behaviour? Denying access to someone
because they don't have the required permission is an effect on the
behaviour. And what does it has to do with Stanbol aiming to be RESTful?

If Stanbol didn't aim at being RESTful but would simply be a set of HTTP
endpoints then one could argue that security could quite easily be provided
at the level of an HTTP Proxy. But apart that this isn't so easy as the
proxy has to be reconfigured for any change of the API or else services
might be inaccessible or unprotected it would only allow for very course
grained restrictions. Many services should just return more limited results
depending on the access right of the user. The sparql enpoint might well be
available but which graphs can actually be queried depends on the user
making the request.


>
> I don't have much details how this aspect is being implemented. But what's
> clear is it does affect the behaviour of the components, and how other
> people are using Stanbol
>
What is clear is that it does unveil some bugs. Mostly bugs that are not
shown by integration tests as there are no integrations tests accessing
remote services.


>
> Therefore, I vote +1 to what Bertrand proposed, until the design of such
> security mechanism is agreed and can be guaranteed would not affect the
> internal behaviour, which in the end in the purpose of the project.
>

Again, what "internal behaviour"? Java code written without thinking about
security does security relevant stuff. E.g. Accessing a file requires a
particular permission. As stanbol components should be runnable in secured
context (this includes application servers) they should not missbehave in
this case. Unfortunately some of code does (see the mail regarding catching
security exception I wrote an hour ago). If you think asking that this is
fixed is a violation of the "internal behavioural freedom" of a component
then the usability of Stanbol components is severly limited.

Cheers,
Reto


>
> Cheers,
>
>
>
> On 05/04/13 13:51, Rupert Westenthaler wrote:
>
>> Hi all,
>>
>> My viewpoint is as follows:
>>
>> * Disabling Security as default: Stanbol is still not functioning to
>> 100% if the Security-Manager is enabled hence IMHO deactivating this
>> feature is the logical consequence.
>>
>> * Enabling Security for IntegrationTests - because when you change
>> things, than it is good to validate if it runs if an SecurityManager
>> is present. Sometimes small changes do break security stuff (e.g. if a
>> library that loads stuff via context classloader is imported from a
>> different bundle the SecurityManager might say NO) ... meaning that
>> even configuration changes might break code ... so having those things
>> tested is important (unless we decide to not support SecurityManager
>> stuff at all - like it is done my Solr, Tika ... but this was part of
>> [1] and I accept the decision)
>>
>> To ensure that Stanbol is 100% working with the Security-Manager
>> enabled is not only the question of fixing all those components. It
>> will also require to test all those components during the
>> integration-tests and as all those components depend on some external
>> services this is not an easy thing to achieve. Because (1) this would
>> also mean that failures of remote services would fail the
>> integration-tests and (2) it will no longer allow to complete the
>> integration-tests while offline.
>> On the other side having not all component tested with active
>> SecurityManager would make it very possible that some minor change
>> (such as a version upgrade of a dependency) could break an component
>> without noticed by the Developer nor the Jenkins build.
>>
>> To Summarize: As long as there are no solutions for those things I
>> would really like to have security deactivated by default. This means
>> that users that are not bordered with it will not run into problems
>> they would not need to boarder with. Users that do need (use) the
>> security features will run into those problems. Those users will also
>> more likely understand those issues and report/patch them.
>>
>> WDYT
>> Rupert
>>
>> p.s.
>> On Fri, Apr 5, 2013 at 9:59 AM, Adrian Gschwend<ml-ktk@netlabs.org>
>>  wrote:
>>
>>> WTF
>>>
>>
>> I hope the this stand for "Want To Fix" otherwise I would recommend to
>> think twice before hitting the send button if the receiver includes a
>> public mailing list ...
>>
>>
>>
>> --
>> | Rupert Westenthaler             rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11                             ++43-699-11108907
>> | A-5500 Bischofshofen
>>
>
> --
> Sergio Fernández
> Salzburg Research
> +43 662 2288 318
> Jakob-Haringer Strasse 5/II
> A-5020 Salzburg (Austria)
> http://www.salzburgresearch.at
>

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