Glenn, As a new feature, you need a majority of votes and at least 3 +1. My vote is -1 ( but is not a veto ). Only commits can be vetoed, and I'll probably do so if castor is used - all tomcat is using digester style for xml processing, and we have a proposal to use JNDI to abstract XML processing. If each piece of tomcat start using another technology - maybe jaxb ? or any other xml-to-java we'll end up with a huge mess.
I also strongly disagree with doing schema validations at runtime ( i.e. on every run ), so if you really want validation it must be done only once ( and at each file modification ) or be done by the config tools. Yes, we have webdav bundled - aparently a majority of voters believed it was a good idea. I think it isn't - and if someone propose to remove it and just recommend slide I'll be +1. But that's not a good argument for adding more. My major concerns are: - integration in a new config mechanism. If you don't like JNDI/JMX proposal, make another one - but we should have a consistent way of dealing with config ( as API ). - castor use. I like castor - and if a proposal is made to use castor in all xml processing, I may be +0. But I'm strongly -1 on using castor for policy, digester for server.xml and DOM for jasper. - DTD - what are jboss or j2ee using for policy ? What other DTDs are in use for this ? XML is just a file format, if everyone uses a different DTD we're in a mess. Again, I'm not vetoing ( I can't anyway ) the proposed new feature, I'm just voting against ( proposals like this are majority votes - at least in my understanding ) Costin Glenn Nielsen wrote: >> >> I'm -0 on adding yet another config file - WEB-INF/policy.xml is also >> strange as webapps ( which shouldn't be trusted ) get to set the security >> policy. This is very tricky - and will need a lot of review. >> > > Using Tomcat with the XML based policy file is optional, so it is another > config file only if it is being used. And I tried to provide good > documentation on how to use it. > > /WEB-INF/policy.xml works. The code is pretty straightforward. Only those > permissions which the global policy.xml allow can be configured in the web > app. This is done using the Permissions.implies() method. > And the web app can only configure permissions for code sources > that exist within its context directory. > > I plan on putting this into production and I am very paranoid when it > comes to security. > >> However I'm -1 on adding deps on castor and doing schema validations - at >> least at this stage ( and after the experience we had with web.xml >> schemas ). Castor is very nice, but is also a big thing. >> > > What experience was it that "we" had with web.xml schemas? I have used > Castor on other projects. It does more than validation, it is also used > to generate Java source code when Tomcat is built for the XML Schema > elements. > > Tomcat on a production system already takes up a huge amount of resources > (memory), I don't think the extra memory required by Castor classes would > be > noticed. And those resources would only get used if you use the XML based > policy files. > >> The current policy file is standard and likely to be understood by tools. >> XML may be in theory easier, however I doubt too many tools understand >> this particular DTD. So I prefer keeping the current file format as >> default, at least until a standard security policy DTD is defined ( >> standard == we're not the only ones using it :-). >> > > The current policy file also has its limitations. This new policy.xml is > more intutitive to configure. Any tool which understands XML can be used > to configure your XML Policy files, such as XML Spy. > > The JVM itself anticipated a need for alternative application specific > Policy implementations and has the hooks for doing it. > > Are you aware of anyone working on a new standard? Is there a JSR? > >> If you need this functionality - I would propose making it a separate >> module ( sort of add-on to tomcat ), instead of bundling it with tomcat >> by default. >> > > This isn't just for me. The type of features the XML Policy code add > have been requested in discussions I have had about the Java > SecurityManager at ApacheCon and JavaOne. > > There currently are no official Tomcat add on modules. Everything comes > bundled with it. There have been discussions about this, the end result > being that it is easier for the user if everything is bundled together. > There are a number of Tomcat features that I don't use such as webdav, > ssi, and cgi to name a few. I just remove those things I don't need. > If you don't need to use the policy based XML, don't use it. > > > Regards, > > Glenn -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
