Hi Luciferis
CC: sahoo
> This way we just have to manage GlassFish security and yet have the
> ability to execute every command that is registered to the Felix >shell,
I have seen your implementation and indeed it is a different way of
handling the issue and I learned a lot. I have some comments about
security as following:
1 if a user firstly used the sub-command to install remote shell, then
enable the telnet, whether the same problem exists or not?
2 even if the user does not install remote shell, if he/she used the
sub-command to install/update/delete gf-managed bundles, then, security
hole may be still exist.
What I understood to secured port has two means:
1) protect gf and user-defined app/bundle from attacking
2) enable/disable remote shell to switch between users with different
requirements
--Best Regard!
--Tang
Ancoron Luciferis wrote:
> Hi together,
>
> I just did a quite different way of handling this issue and still have
> every Felix shell command (whether from upstream or custom ones) at my
> hands:
>
> 1.) don't deploy/start the remote shell
> 2.) provide a simple asadmin sub-command that acts as a bridge between
> the GlassFish administration interface and the Felix Shell
>
> This way we just have to manage GlassFish security and yet have the
> ability to execute every command that is registered to the Felix shell,
> like this (gogo version - standard):
>
> $ ./bin/asadmin -t felix frameworklevel
> Level is 3
>
> ...or with the felix shell instead of gogo:
>
> $ ./bin/asadmin -t felix startlevel
> Level 3
>
> ...it allows as many arguments as you like:
>
> $ ./bin/asadmin -t felix find weld
> START LEVEL 3
> ID State Level Name
> [ 14] [Active ] [ 1] Weld integration for glassfish (3.1.2)
> [ 143] [Resolved ] [ 1]
> org.glassfish.main.web.weld-integration-fragment
> [ 193] [Resolved ] [ 1] Weld OSGi Bundle (1.1.4.Final)
>
> ...
>
> I've just pushed the latest code and did a small release for this artifact.
>
> You can get it here (it doesn't require any additional stuff but needs
> GlassFish 3.1.2 at least - OSGi core 4.3):
>
> https://oss.sonatype.org/content/repositories/releases/org/ancoron/glassfish/asadmin/org.ancoron.glassfish.asadmin.felix.shell/1.0.5/org.ancoron.glassfish.asadmin.felix.shell-1.0.5.jar
>
> ...the code is here:
>
> https://github.com/ancoron/gf-samples/tree/master/asadmin-ext/felix-shell
>
>
> Cheers,
>
> Ancoron
>
>
> On 07/11/2012 05:09 PM, Sahoo wrote:
>> Hi Tang,
>>
>> Thanks for looking into it. With this proposal, once the remote shell is
>> enabled, the security issue described in the bug still remains. Can you
>> think of any way to make the port secured such that only users
>> authneticated using glassfish admin user name& password can access the
>> port.
>>
>> Thanks,
>> Sahoo
>>
>>> Dear Sahoo, Tom
>>>
>>> About GLASSFISH-16998 and GLASSFISH-13006, I have a design idea
>>> and want to discuss with you.
>>>
>>> My design idea is as following:
>>>
>>> 1 "Turn off" org.apache.felix.shell.remote bundle
>>> Just as Richard S. Hall said:
>>>
>>> "From an OSGi perspective, the way to administratively turn off a bundle
>>> is to stop it or not deploy it. "
>>>
>>> I think that Stoping shell.remote bundle is a better way on the current
>>> gf architecture.
>>>
>>> Because on the current gf's code, GlassFishActivator class and
>>> GlassFishActivator.startPostStartupBundles() have not been existed, I
>>> think that the better way is to modify OSGiGlassFishRuntimeBuilder.build
>>> method and add the logic to stop org.apache.felix.shell.remote bundle
>>> behind "framework.start()" .
>>>
>>> 2 provide a way to administratively turn on shell.remote bundle
>>>
>>> Just as said on GLASSFISH-13006, felix shell is also important not only
>>> for framework developers(re-develop based gf), but also for OSGi app
>>> developers.However, also need to consider people who are not interested
>>> in OSGi. In addition, considering administrative and security aspects, I
>>> think that:
>>>
>>> Supporting a admin cli command for turning on shell.remote bundle,
>>> liking the following:
>>>
>>> asadmin start-felixremoteshell --telnet.port<portvalue> --portsavedfile
>>> <filepath>
>>>
>>> About design of the command,
>>> 1) --telnet.port is optional, if not inputing, gf will select an unused
>>> port randomly.
>>> 2) after executing the command, gf will display the port value on
>>> os-related shell window in order to let the user to know the port.
>>> 3) --portsavedfile is optional, if not inputing, gf will save the port
>>> value on a file of "user.home" by means of enciphering the port value.
>>> 4) when executing the command again, if user does not input port value,
>>> gf will firstly read port value from the portsavedfile, and if can't
>>> get the port value from the portsavedfile, then, executing the logic of
>>> 1) and updating the portsavedfile.
>>>
>>> --Best Regard!
>>> --Tang
>>>
>
>
>