-
30. Re: VFS Permissions - JBMICROCONT-149
https://jira.jboss.org/jira/browse/JBCL-64
I took the low hanging fruit for now. I am able to get the server to boot under a security manager. I still have to figure out some missing permissions but not a vfs issue. -
31. Re: VFS Permissions - JBMICROCONT-149
"anil.saldhana@jboss.com" wrote:
https://jira.jboss.org/jira/browse/JBCL-64
I took the low hanging fruit for now. I am able to get the server to boot under a security manager. I still have to figure out some missing permissions but not a vfs issue.
I have created a subtask to investigate a better long term solution.
At this time, I just change the protocol to be "file" instead of the vfs protocol. Adrian, do you see issues? -
32. Re: VFS Permissions - JBMICROCONT-149
"anil.saldhana@jboss.com" wrote:
At this time, I just change the protocol to be "file" instead of the vfs protocol.
Anil, I've refactored your code a bit.
Leaving the old behavior as default - via your CodeSourceGenerator,
but I'll provide proper hooks so that this can be overridden in the CL deployers that use VFSCLPolicy.
If Adrian agrees this is a proper fix. ;-) -
33. Re: VFS Permissions - JBMICROCONT-149
"alesj" wrote:
"anil.saldhana@jboss.com" wrote:
At this time, I just change the protocol to be "file" instead of the vfs protocol.
Anil, I've refactored your code a bit.
Leaving the old behavior as default - via your CodeSourceGenerator,
but I'll provide proper hooks so that this can be overridden in the CL deployers that use VFSCLPolicy.
If Adrian agrees this is a proper fix. ;-)
I like your refactor. Are you going to provide the hooks by Monday? I want to enable the security manager tests in AS5 asap. I also have changes that I need to check in changes in AS5 code (privileged blocks) as part of that. -
34. Re: VFS Permissions - JBMICROCONT-149
"anil.saldhana@jboss.com" wrote:
"alesj" wrote:
"anil.saldhana@jboss.com" wrote:
At this time, I just change the protocol to be "file" instead of the vfs protocol.
Anil, I've refactored your code a bit.
Leaving the old behavior as default - via your CodeSourceGenerator,
but I'll provide proper hooks so that this can be overridden in the CL deployers that use VFSCLPolicy.
If Adrian agrees this is a proper fix. ;-)
I like your refactor. Are you going to provide the hooks by Monday? I want to enable the security manager tests in AS5 asap. I also have changes that I need to check in changes in AS5 code (privileged blocks) as part of that.
I don't like it refactored or otherwise because it is wrong.
There are two different issues:
1) Which codesource should it use?
i.e. should it use the top level file: url like JBoss4 or a vfs url as the codesource
This is what you CodeSourceGenerator abstraction is trying to do, but it is a hack
and it also only applied to the vfs classloading spi?
If we are going to go to the effort of introducing a proper spi for this,
then we should look at how you override the real purpose of this policy,
i.e. determing the whole ProtectionDomain.
There should also be easier ways to set this policy, i.e. on the ClassLoaderDomain
or the ClassLoaderSystem itself.
The FileProtocolCodeSourceGenerator is wrongly implemented anyway.
e.g. vfsfile:/some/directory/my.jar/sub.jar would result it a file url that is invalid
file:/some/directory/my.jar/sub.jar
I also don't see the need for the permission to set the codesource generator.
If somebody can get access to the policy then can make all sorts of other
changes anyway. Getting access to the classloader
implementation objects is already controlled bysm.checkCreateClassLoader();
checks.
2) What permissions should it have?
i.e. do you get the necessary FilePermission, checkConnection and NetPermissions?
If you change the code source to be a file: url for the parsing of java.policy
then you are going to loose the rights to use vfsxxx url
(and vice versa).
That's besides the problem mentioned above with the wrong file url getting used. -
35. Re: VFS Permissions - JBMICROCONT-149
"adrian@jboss.org" wrote:
I don't like it refactored or otherwise because it is wrong.
There are two different issues:
1) Which codesource should it use?
i.e. should it use the top level file: url like JBoss4 or a vfs url as the codesource
This is what you CodeSourceGenerator abstraction is trying to do, but it is a hack
and it also only applied to the vfs classloading spi?
I say it is a hack because it is not the job of the classloader to map
vfs urls to other urls. We should be asking to the VFS subsystem to do this.
This kind of negates the need for the CodeSourceGenerator abstraction altogether
with the only question being a policy of which url you use as the code source.
(The permissions should be the same regardless of how you identify the code). -
36. Re: VFS Permissions - JBMICROCONT-149
Currently, the classloader system is the issue to get AS5 working under a security manager. Your approach of security.xml did the same (introduction of SM after the CL).
file:/some/directory/my.jar/sub.jar is still being opened and its permissions read by the Policy implementation. This is where we have issues. We cannot read the vfs urls and the introduction of the VFS handlers into bootstrap is unknown territory at the moment. -
37. Re: VFS Permissions - JBMICROCONT-149
"adrian@jboss.org" wrote:
I also don't see the need for the permission to set the codesource generator.
If somebody can get access to the policy then can make all sorts of other
changes anyway. Getting access to the classloader
implementation objects is already controlled bysm.checkCreateClassLoader();
checks.
An uninitiated system administrator configuring the security manager policy can wrongly configure any user applications to have "all" permissions, which means any controls we have placed for security are negated (including checkCreateCL). -
38. Re: VFS Permissions - JBMICROCONT-149
"anil.saldhana@jboss.com" wrote:
Currently, the classloader system is the issue to get AS5 working under a security manager. Your approach of security.xml did the same (introduction of SM after the CL).
file:/some/directory/my.jar/sub.jar is still being opened and its permissions read by the Policy implementation.
It can't do, the URL is invalid. The correct permission is to be able to read
file:/some/directory/my.jar
This is where we have issues. We cannot read the vfs urls and the introduction of the VFS handlers into bootstrap is unknown territory at the moment.
But if you fix that problem (which from my point of view you don't need to do
since the security.xml solves the problem and makes the configuration easier)
then the issue is what permissions you add to the class based on the codesource.
If the VFS URLHandler had its own permission which implied the relevant
file/socket/net permission(s) then all we'd need to do is retrieve that permission
from the VFS url and add it.
e.g.
new VFSPermission("vfsfile:/blah/path/file", ...) imples
new FilePermission("/blah/path/file", ...)
and similarly for whatever is required for zip/jar files
This removes the url hacking for permissions and places the url mapping problem in the
VFS url handlers where they belong.
The url hacking is still required if somebody wants to use the file: url as the codesource,
but it must be the correct one, i.e. the url of the top level jar file. -
39. Re: VFS Permissions - JBMICROCONT-149
"anil.saldhana@jboss.com" wrote:
"adrian@jboss.org" wrote:
I also don't see the need for the permission to set the codesource generator.
If somebody can get access to the policy then can make all sorts of other
changes anyway. Getting access to the classloader
implementation objects is already controlled bysm.checkCreateClassLoader();
checks.
An uninitiated system administrator configuring the security manager policy can wrongly configure any user applications to have "all" permissions, which means any controls we have placed for security are negated (including checkCreateCL).
I don't see your point? If the administrator configures it wrong then
there's nothing we can do about it.
That's like saying you should ban cutlery because you can stab yourself in the eye
with a fork. ;-) -
40. Re: VFS Permissions - JBMICROCONT-149
"adrian@jboss.org" wrote:
"anil.saldhana@jboss.com" wrote:
"adrian@jboss.org" wrote:
I also don't see the need for the permission to set the codesource generator.
If somebody can get access to the policy then can make all sorts of other
changes anyway. Getting access to the classloader
implementation objects is already controlled bysm.checkCreateClassLoader();
checks.
An uninitiated system administrator configuring the security manager policy can wrongly configure any user applications to have "all" permissions, which means any controls we have placed for security are negated (including checkCreateCL).
I don't see your point? If the administrator configures it wrong then
there's nothing we can do about it.
That's like saying you should ban cutlery because you can stab yourself in the eye
with a fork. ;-)
I am commenting on "I also don't see the need for the permission to set the codesource generator.
| | If somebody can get access to the policy then can make all sorts of other
| | changes anyway. -
41. Re: VFS Permissions - JBMICROCONT-149
"anil.saldhana@jboss.com" wrote:
I don't see your point? If the administrator configures it wrong then
there's nothing we can do about it.
That's like saying you should ban cutlery because you can stab yourself in the eye
with a fork. ;-)
I am commenting on "I also don't see the need for the permission to set the codesource generator.
| | If somebody can get access to the policy then can make all sorts of other
| | changes anyway.
So was I. If somebody has the createClassLoader permission then they can
do whatever they like. e.g. create their own classloader where the classes
get any permission they want to assign. Or give them a codesource
they know has AllPermission, etc. -
42. Re: VFS Permissions - JBMICROCONT-149
Here is how I see things:
a) We need to be able to start the security manager along with the Java process. For this to happen, we should be able to allow the JDK policy implementation to read the security policy file for the permissions assigned to the various codesource URLs.
b) We can NOT inject our own policy implementation which will basically get away from the years of testing the JDK implementation has gone through. We are not just talking about the Sun JDK implementation here. There are other jvm implementations that have differing implementations but they all concur on reading the default policy file format.
c) Every permission is configurable for a piece of jar that is loaded from a particular location, be it file: or be it vfsurl: So your question of assigning NetPermission etc should be taken care of.
In a nutshell, your VFSClassloaderPolicy generating a protection domain
can stay the same. But we really need to have a map of vfs urls to a standard URL instances for the CodeSource.
So should we provide a map of vfsurls to regular URLs to the codesource generators?
something like:<bean name="IamACodeSourceGenerator"> <map key="vfsurl:/somejar" value="file:/somejar" /> <map key="vfsurl:/xyz.jar" value="http:/xyz.jar" /> </bean>
Adrian, I know you disagree. But I do not see creating a vfs policy implementation before AS5GA. -
43. Re: VFS Permissions - JBMICROCONT-149
"adrian@jboss.org" wrote:
e.g. vfsfile:/some/directory/my.jar/sub.jar
This would actually be vfszip:/some/directory/my.jar/sub.jar,
if my.jar or sub.jar are really archives. ;-)
I'll revert Anil's changes to VFSCLPpolicy. -
44. Re: VFS Permissions - JBMICROCONT-149
"alesj" wrote:
"adrian@jboss.org" wrote:
e.g. vfsfile:/some/directory/my.jar/sub.jar
This would actually be vfszip:/some/directory/my.jar/sub.jar,
if my.jar or sub.jar are really archives. ;-)
I'll revert Anil's changes to VFSCLPpolicy.
WHY? Stop doing all this cleanup. We are doing a discussion here. Go do something else.