karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Database commands for Karaf
Date Mon, 16 Jan 2012 09:20:38 GMT
Hi Achim,

FYI, last week I raised:

The purpose is to use the Karaf JAAS layer (and group especially), to 
define security policy associated (for instance, this group can launch 
this command or access to this MBean, but not this group).


On 01/16/2012 10:11 AM, Achim Nierbeck wrote:
> Hi,
> I pretty much liked the idea of Claus, that a "app-store" kind-of-thing
> could be the home for such neat shell/other-stuff improvments on top of
> Karaf.
> I'm -1 for adding it into the scope of Karaf, cause it's plainly out of
> scope. Never the less I think this is quite a handy shell command that
> could be
> quite useful for debugging purposes.
> Now my 2 cents about the security stuff, I'm absolutely with Clause, that
> the security system inside Karaf needs some improvments, not all commands
> available should be executable for everyone. So a role-based security
> system is needed here, and it might be even needed to prevent to install
> certain shell commands
> cause they might be of "risk" like the db-commands :)
> Regards, Achim
> 2012/1/15 Andreas Pieber<anpieber@gmail.com>
>> 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 think that they'll better fit into other projects. I
>> would like to wait some days what the Aries guys think about the proposal
>> (I'll answer there too later today). Independently I like the idea of some
>> kind of Karaf-Team-Maintained-Enterprise-Command-Repository. Maybe we could
>> host it at github since it's ways fast to release/maintain there. We can
>> use the Karaf lists and issue tracker to work on them but have more
>> freedom. E.g. github.com/karaf or karaf-extras. If we allow only
>> contributions for ppl signed the CLA or via the Karaf issue tracker we
>> could in addition move those projects freely to karaf if we feel they're
>> ready for the core or a sub-project.
>> @Security: maybe start a new thread based on Claus's suggestions. I think
>> this could be a good target for Karaf-3.x/4.x (depending on how deep we
>> need to cut into Karaf for the various changes.
>> Kind regards,
>> Andreas
>> 2012/1/15 Łukasz Dywicki<luke@code-house.org>
>>> 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/password when
>>>> executing the SQL using the Karaf commands, then that is better.
>>> We can introduce a multiple roles and then operator can grant access to
>>> execute given command group. OSGi PermissionAdmin is another place which
>>> can be involved in security checks.
>>> Best regards,
>>> Łukasz Dywicki
>>> --
>>> Code-House
>>> http://code-house.org

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message