10:52 a.m.
The AS codebase now supports running under a security manager. Well,
sort of. There are a few places where we need privileged blocks and/or
permission checks, but you can boot up AS under a security manager today
if you want. Just follow these steps:
1. Modify standalone.sh so that the -secmgr flag is passed in to JBoss
Modules.
Well, I guess there's just the one step. Anyway I've noticed that the
impact on startup time is not as bad as I had expected, which is good.
So the question is: Should we set up a security manager-enabled test
run? How should it work?
--
- DML
11:30 a.m.
IMO we should have dedicated SM enabled test runs. We used
to have it regularly but it fell out of preference. :)
On 02/28/2013 09:52 AM, David M. Lloyd wrote:
The AS codebase now supports running under a security manager.
Well,
sort of. There are a few places where we need privileged blocks and/or
permission checks, but you can boot up AS under a security manager today
if you want. Just follow these steps:
1. Modify standalone.sh so that the -secmgr flag is passed in to JBoss
Modules.
Well, I guess there's just the one step. Anyway I've noticed that the
impact on startup time is not as bad as I had expected, which is good.
So the question is: Should we set up a security manager-enabled test
run? How should it work?
11:33 a.m.
Perhaps the pull request job should be set up to use the security manager, and the
master-ignore job to not use a security manager (or the other way round). That way pretty
much everything should be tested both ways before merged upstream.
Then the question is what to do with the master job which runs every time something is
merged into master. Perhaps we need another job, running once a day, which runs with the
opposite security manager config from the master job?
On 28 Feb 2013, at 15:52, David M. Lloyd wrote:
The AS codebase now supports running under a security manager. Well,
sort of. There are a few places where we need privileged blocks and/or
permission checks, but you can boot up AS under a security manager today
if you want. Just follow these steps:
1. Modify standalone.sh so that the -secmgr flag is passed in to JBoss
Modules.
Well, I guess there's just the one step. Anyway I've noticed that the
impact on startup time is not as bad as I had expected, which is good.
So the question is: Should we set up a security manager-enabled test
run? How should it work?
--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
---------------------------------------
Kabir Khan
Prinicipal Software Engineer
JBoss by Red Hat
10:50 a.m.
On 2/28/13 10:33 AM, Kabir Khan wrote:
Perhaps the pull request job should be set up to use the security
manager, and the master-ignore job to not use a security manager
Sounds good. Everything goes through param-pull, so make it the most
stringent.
My assumption is it would be a rare thing to introduce a bug that passes
with a security manager but fails without.
(or the other way round).
Less good. I occasionally skip master-ignore and just merge something
once it's passed param-pull, if I know the param-pull test ran against
latest master. I roll the dice that the teamcity Windows tests of
master-ignore wouldn't have found a problem. :) But I wouldn't want to
roll the dice on both security manager and Windows.
That way pretty much everything should be tested both ways before
merged upstream.
Then the question is what to do with the master job which runs every time something is
merged into master. Perhaps we need another job, running once a day, which runs with the
opposite security manager config from the master job?
+1. I'd say the regular master job runs with the security manager.
Again, make the more common test the more stringent one.
On 28 Feb 2013, at 15:52, David M. Lloyd wrote:
> The AS codebase now supports running under a security manager. Well,
> sort of. There are a few places where we need privileged blocks and/or
> permission checks, but you can boot up AS under a security manager today
> if you want. Just follow these steps:
>
> 1. Modify standalone.sh so that the -secmgr flag is passed in to JBoss
> Modules.
>
> Well, I guess there's just the one step. Anyway I've noticed that the
> impact on startup time is not as bad as I had expected, which is good.
>
> So the question is: Should we set up a security manager-enabled test
> run? How should it work?
> --
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
---------------------------------------
Kabir Khan
Prinicipal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4071
days inactive
4072
days old
3 comments
4 participants
participants (4)
-
Anil Saldhana -
Brian Stansberry -
David M. Lloyd -
Kabir Khan