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 <l...@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 > >
