That's a good point, and we indeed had the same requirements for Karaf.
As indicated by Christian, guarding the Function registered services was
the initial way of handling the problem.
In recent Karaf versions however, things have changed slightly, mainly
because in Karaf, Gogo does not access commands directly from the OSGi
registry anymore.
Usually, Karaf commands are not registered in the OSGi registry, so we can
more easily wrap them and add security bits.

Last, I've recently added 2 interception points,
CommandProcessorImpl.invoke and CommandProcessorImpl.redirect which Karaf
overrides to add security checks too.
Those controls invocation through reflection and shell redirections.  You
do want to add checks here in a secured environment.

Gogo would definitely benefit from having a correct interception layer for
security...  This would include those 2 last points along with visibility /
execution for commands.


2018-03-03 22:52 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:

> Apache karaf has something like this.
> It uses a find hook to intercept services and add jaas + ACL based security
> checks.
>
> See:
> https://github.com/apache/karaf/tree/master/service/
> guard/src/main/java/org/apache/karaf/service/guard/impl
>
> Actually I think this is something we could also build into felix gogo.
>
> Christian
>
>
> 2018-03-02 7:03 GMT+01:00 David Leangen <o...@leangen.net>:
>
> >
> > Hi!
> >
> > I would like to implement a security feature in the command line, much
> > like I would do in a servlet. Is there an easy way to intercept command
> > calls so I can wrap each call with the security feature?
> >
> > Right now, I have to do something like this for each command method in my
> > component:
> >
> > return auth.call( () -> {
> >    [code goes here];
> > });
> >
> > It would be preferable to do this just once for all commands, rather than
> > having to wrap each command individually. I would prefer not to have to
> use
> > a proxy object (makes it harder to debug) or create my own whiteboard
> > service host (a bit heavy-handed, taking the code further away from
> GOGO).
> >
> >
> > Cheers,
> > =David
> >
> >
> >
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>



-- 
------------------------
Guillaume Nodet

Reply via email to