Hi David,
even without the prepend (+) in the configuration file (your latest
commit), the issue is still present.
If you check the spring features XML in the system repo, it's correct
(containing the 3.1.0.RELEASE spring features), but when you type
features:list-url + features:list, the fe
Hi David,
At least, we can change the import of slf4j as optional (it works on my
local copy).
I will take a look this morning in order to fix the issue in Karaf trunk.
Regards
JB
On 01/16/2012 05:21 AM, David Jencks wrote:
This commit :
commit c22c2ce55671d14210d1f412b4df80048d6ef3db
Auth
This commit :
commit c22c2ce55671d14210d1f412b4df80048d6ef3db
Author: Harald Wellmann
Date: Fri Jan 13 21:19:03 2012 +0100
[PAXURL-156] Use Pax Swissbox 1.5.0
introduced an import-package for org.slf4j.impl in at least
pax-url-obr
pax-url-war
pax-url-wrap
Since this is not exported by p
Well, TBH as long as we do not lay down our roadmap what we expect from
Karaf's application service security (although Claus wrote down quite a
detailed idea :-)) I somehow have the feeling that this is the wrong thread
for a discussion about the security of those commands.
-->
@Commands: I still t
In reply to Claus Ibsen mail
> Well there is a problem, if anyone who can ssh into karaf, can execute
> any arbitrary SQL against any data sources deployed, and being able to
> hide using the credentials from the application level data source. If
> the user would always have to provide a username/
I think the remaining issue here (unsatisfied wiring constratnt to
(osgi.wiring.package=org.slf4j.impl))) means someone broke pax-url-wrap since
that package isn't exported at all by the pax-logging bundles.
thanks
david jencks
On Jan 14, 2012, at 2:19 PM, David Jencks wrote:
> When I removed
On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider
wrote:
> I see no real security problem in the commands themselves. The DataSource is
> a security risk though. Typically datasources are defined with full
> credentials of a technical user that may access the database. So whoever
> logs into ka
On Sun, Jan 15, 2012 at 1:43 PM, David Jencks wrote:
> I don't quite understand the security problem, but maybe I'm thinking of a
> different environment. I would expect an environment where the db enforces
> user level access to that user's data to be set up in the app server using
> containe
I see no real security problem in the commands themselves. The
DataSource is a security risk though. Typically datasources are defined
with full credentials of a technical user that may access the database.
So whoever logs into karaf has access to the db with that technical
user. Typically on a
I don't quite understand the security problem, but maybe I'm thinking of a
different environment. I would expect an environment where the db enforces
user level access to that user's data to be set up in the app server using
container based security, where the app server maps the user identity
Hi
At first thought the commands seems cool.
However one part (the SQL execute) they risk introduce a security
vulnerability, as a malicious user can use these commands to access
production database, and manipulate the data. And by using the same
datasource/connection that applications uses, so i
Hi Andreas,
I am ok with a subproject though I think the code is currently much too
small to warrant a subproject. That may change of course.
Outside of Karaf I see no obvious host projects for generic commands
like db or jms. By design these commands should not be provider
specific. So a speci
12 matches
Mail list logo