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
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 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
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
On Sun, Jan 15, 2012 at 1:43 PM, David Jencks david_jen...@yahoo.com 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
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
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
This commit :
commit c22c2ce55671d14210d1f412b4df80048d6ef3db
Author: Harald Wellmann harald.wellm...@gmx.de
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
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
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
10 matches
Mail list logo
