+1 for this proposal. I like the idea that we needn't change current commands code, but hack it through service registry hooks. ------------- Freeman(Yue) Fang
Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-8-15, at 下午10:26, dav...@apache.org wrote: > Hi all, > > In the context of KARAF-2442 I started looking at securing the commands in > the shell. I wanted to do something similar to what I did for the JMX > access (KARAF-2435) in that this should be configurable by a Karaf > administrator. I also really wanted a generic solution that would work with > all commands, so that there would not be a big burden on the command > developer. I know that there was discussion about this in the context of > Karaf before, my approach here is a bit different... > > Here's what I came up with… > Karaf Commands are implemented OSGi services and one of the lesser known > features of the OSGi service registry is the fact that you can control > service registrations through service registry hooks. This effectively > allows you to change registrations, control who sees what registrations and > also proxy service objects with some interceptor [1]. > I thought that this might be a nice tool to use to add security to the > Karaf Commands from the outside, so I started an experimental > implementation with this: > * The roles that a specific Karaf Command needs in order to be executable > are defined in a ConfigAdmin config file in the etc/ directory. So this can > easily be modified by an administrator. E.g I have a file that controls who > can use the feature command, some example content: > list = manager, viewer > install = manager > uninstall = admin > * I added a mechanism that effectively changes command service > registrations to add the required roles for the specific command - based on > the ConfigAdmin data specified, e.g. the Service Registration for a > features:list command is turned into the following: > osgi.command.scope=feature > osgi.command.function=list > org.apache.karaf.command.roles=[manager,viewer] > * The CommandProcessorImpl class in Karaf keeps track of what commands are > there. Previously this was a global instance, but now we need one instance > per shell console that selects the right commands for the user of that > console. It does this by reading off the current RolePrincipal objects > (that were put there by the JAAS login) and only selecting those commands > that have these roles by simply adding these as additional conditions to > the OSGi Service Registry selection filter. > * From there on everything works as normal. Tab completion etc, 'just > works'. > > The commands themselves are not modified. The required roles are added > externally, which is really easy for the command developer. > It's also pretty easy to change the required roles for commands either > directly in the etc/...cfg files or via the ConfigAdmin API... > > There are still a few things that I need to look at in more detail > (including defaults), but I wanted to run this by everyone to see what > people think, so feedback is appreciated! > If you're interested, I implemented this on a branch here: > https://github.com/bosschaert/karaf/commit/3e16bb515350bfb58e1a4b5d98045ccc1bcb1630 > > David > > dav...@apache.org > da...@redhat.com > david.bosscha...@gmail.com > > [1] Detail: you don't really change a service registration, but can hide it > from bundles and replace it with an alternative, which gives this effect… I > wrote a blog about this a while ago: > http://coderthoughts.blogspot.ie/2009/11/altering-osgi-service-lookups-with.html