Hi Achim,
FYI, last week I raised:
https://issues.apache.org/jira/browse/KARAF-1148
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).
Regards
JB
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<[email protected]>
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<[email protected]>
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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
