November 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Deployment Framework] - Re: move lib-opt under the corresponding deployer

by charles.crouch＠jboss.com

Bump. As of r80658 I'm still seeing \server\default\lib-opt. Dimitris' idea seems like a good one, this way deployers in the future, which sometimes need additional jar's, don't need to all throw stuff in \lib-opt. So how about making this change? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188162#4188162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188162

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149 (Repost)

by adrian＠jboss.org

"anil.saldhana(a)jboss.com" wrote : anonymous 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188156#4188156 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188156

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by clebert.suconic＠jboss.com

I was assuming you replicated the issue... I was just saying this could also happen without the loopback. Maybe Brian wants to add a similar test like you did on JBAS to avoid regressions? Well.. I don't know.. if you keep that test on the JGroups testsuite maybe we don't need to do anything? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188157#4188157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188157

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by adrian＠jboss.org

"anil.saldhana(a)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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188156#4188156 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188156

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by vblagojevic＠jboss.com

Ok, might be. It could also be increased concurrency of channel startup in AS. Unfortunately, we don't currently have an option to test extensively concurrent shared transport startup in jgroups. AS tests are our best option. Why don't you guys make a test that repeatedly does what Brian suggested: joining a few channels on two AS nodes where each node has a shared startup and each channel does either connect and state transfer or separate connect and getstate. I will have a fix soon I hope. Vladimir View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188155#4188155 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188155

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by anil.saldhana＠jboss.com

"adrian(a)jboss.org" wrote : "anil.saldhana(a)jboss.com" wrote : "adrian(a)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 by | | | | | | | sm.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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188154#4188154 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188154

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by adrian＠jboss.org

"anil.saldhana(a)jboss.com" wrote : "adrian(a)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 by | | | | | sm.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. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188151#4188151 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188151

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by adrian＠jboss.org

"anil.saldhana(a)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 anonymous wrote : | 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188149#4188149 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188149

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by clebert.suconic＠jboss.com

I don't think this is to the loopback? I had this error with and without the loopback on (in a test I did last week). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188146#4188146 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188146

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by anil.saldhana＠jboss.com

"adrian(a)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 by | | | sm.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). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188145#4188145 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188145

17 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2008