Costin Manolache wrote: > 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.
This code only does validation when the container is started or when a web application context is reloaded. The current implementation using the standard policy file does the same thing only not with XML. > > 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 only point is that the current policy is to bundle everything in the Tomcat releases and not provide downloads for separate add on modules. We can discuss whether we want to change that policy. > 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. > I agree with you in principal. From having worked with the code in Tomcat which uses the digester and the code which the admin application uses for marshalling XML, the current Tomcat 4 code for configuration management looks very "brute force". I have been thinking about how the current code works and whether Castor would be a much simpler solution. > - 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. > I very much doubt if any servlet/J2EE containers use the same configuration methods. This is something the specs leave up to the individual implementation. > 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 > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
