Filip Hanik - Dev Lists wrote:
> Mladen Turk wrote:
>> Filip Hanik - Dev Lists wrote:
>>> Mladen Turk wrote:
This simply has to stop.
>>>
>>> taking trunk away, this turn of events is expected. I wish everyone
>>> would have thought of that before we got caught up in the personal,
>>> and
Mark Thomas wrote:
Remy Maucherat wrote:
Tim Funk wrote:
2) If a deploy tool is used which is doing checks - adding an extra
check to allow/deny/restrict scope should not be too hard to do. Since
users can disable symlink checks in the same class (FileDirContext) -
the same exposure could be ha
On Sep 14, 2007, at 11:08 PM, Bill Barker wrote:
Now, I'd prefer that TC is just the Servlet/JSP container
that it is meant to be, and not try to add on proprietary
features. But
that is just me ;).
Others too I think.
Open Source, esp open source at the ASF, has a long and useful
tradit
Costin Manolache wrote:
>
> Regarding feedback on patch - I think I expressed my concerns:
> - more analysis and understanding of security implications
> - if possible to do it at a different (higher) level
> - if it can be done in a modular fashion, i.e. keeping the default impl the
> way it is,
Filip Hanik - Dev Lists wrote:
>
> > I'll vote +1 for bringing trunk back any time when I see
> > your TODO list. Sorry but without that Tomcat6 is not Tomact6
> > but rather your personal (and anyone else) playground.
> bummer, I guess you never saw this
> http://marc.info/?l=tomcat-dev&m=1186461
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
This simply has to stop.
taking trunk away, this turn of events is expected. I wish everyone
would have thought of that before we got caught up in the personal,
and not what is important, trunk debate.
I did, as well
As everyone will see ... I reverted. Its not the end of the world if
this gets in since I can easily maintain a private version with alias
support for myself. I thought it was a helpful bloatage for others. It
might be worthwhile keeping the discussion active for the moment if
anyone else has o
On 9/15/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> Costin Manolache wrote:
> >
> > Well, regarding the veto - it's simple. I second Remy's opinion that the
> > veto is valid
> > and the change is not right at the moment, and I guess that should
> close
> > this discussion.
> >
> > The discus
Costin Manolache wrote:
>
> Well, regarding the veto - it's simple. I second Remy's opinion that the
> veto is valid
> and the change is not right at the moment, and I guess that should close
> this discussion.
>
> The discussion about whether to add such a feature or not - I think a simple
> vo
Well, regarding the veto - it's simple. I second Remy's opinion that the
veto is valid
and the change is not right at the moment, and I guess that should close
this discussion.
The discussion about whether to add such a feature or not - I think a simple
vote
would solve this as well, it's quite a
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
This simply has to stop.
taking trunk away, this turn of events is expected. I wish everyone
would have thought of that before we got caught up in the personal, and
not what is important, trunk debate.
I did, as well others did (I hope)
Mladen Turk wrote:
Bill Barker wrote:
Now, I'd prefer that TC is just the Servlet/JSP container that it is
meant to be, and not try to add on proprietary features. But that is
just me ;).
You are not the only one ;)
Seems we have lost the clear vision of the project somewhere
in the flam
Remy Maucherat wrote:
I tested with the security manager, and it doesn't behave correctly.
If the context.xml inside a webapp is:
The docBase hack attempt doesn't do anything (it's overwritten, I
think), but the security manager does not prevent browsing the HD as the
policy grants all p
Remy Maucherat wrote:
> Tim Funk wrote:
>> 2) If a deploy tool is used which is doing checks - adding an extra
>> check to allow/deny/restrict scope should not be too hard to do. Since
>> users can disable symlink checks in the same class (FileDirContext) -
>> the same exposure could be had with a
Tim Funk wrote:
2) If a deploy tool is used which is doing checks - adding an extra
check to allow/deny/restrict scope should not be too hard to do. Since
users can disable symlink checks in the same class (FileDirContext) -
the same exposure could be had with a little more effort.
I'm not tr
Bill Barker wrote:
Now, I'd prefer that TC is just the Servlet/JSP container
that it is meant to be, and not try to add on proprietary features. But
that is just me ;).
You are not the only one ;)
Seems we have lost the clear vision of the project somewhere
in the flame wars.
It has beco
"Remy Maucherat" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Peter Rossbach wrote:
>> Hi,
>>
>> I like this FileDirContext extension. It is a very nice way to include
>> external content without symlinks!
>
> I'm not hot about it, and this seems like a a sort of superset of the
Hopefully I can get all the concerns in one email ...
[Pardon me if this is not the most coherent - I been on vacation this
week and I was staining and putting sealer or some wood furniture and
got too many fumes to the head ... but don't let that reflect badly on
the patch ... that was done we
Filip Hanik - Dev Lists wrote:
I totally accept that you dont like the policy, but it doesn't justify
vetos. and that has been one of the core of the issues.
the one time it would fly for a veto would be when, a) others feel the
same, b) no one likes the feature
I detailed a number of reason f
Jim Jagielski wrote:
Filip agreed that if it went against the specification then
the patch had no place being committed. In fact, I think
everyone did :)
If, however, the specification is moot, then the decision
on "how much to add in response to user or developer
desire" is, I think we all agre
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Yes, this is hard to compare to httpd, as in the case of Tomcat,
there is precise specification which defines a portable web
application packaging. I see the latest changes have all aimed at
breaking portability, and I
On Sep 14, 2007, at 4:27 PM, Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Writing a portable webapp, is doable, and essentially has nothing
to do with the optional feature set in Tomcat. If you want a
portable webapp, simply don't use the non portable features in
Tomcat.
It's an
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Yes, this is hard to compare to httpd, as in the case of Tomcat, there
is precise specification which defines a portable web application
packaging. I see the latest changes have all aimed at breaking
portability, and I don't like that at all
On Sep 14, 2007, at 3:50 PM, Remy Maucherat wrote:
Jim Jagielski wrote:
On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:
It may also have some implications on other use cases -
deployment ( the
current pattern
is that all files for a webapp are in one place ), replication
( i.e. if
Remy Maucherat wrote:
Jim Jagielski wrote:
On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:
It may also have some implications on other use cases - deployment (
the
current pattern
is that all files for a webapp are in one place ), replication (
i.e. if
someone wants same webapps
on
Jim Jagielski wrote:
On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:
It may also have some implications on other use cases - deployment ( the
current pattern
is that all files for a webapp are in one place ), replication ( i.e. if
someone wants same webapps
on a pool of servers ).
To
On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:
It may also have some implications on other use cases - deployment
( the
current pattern
is that all files for a webapp are in one place ), replication
( i.e. if
someone wants same webapps
on a pool of servers ).
To me this is an im
On Sep 14, 2007, at 3:30 PM, Filip Hanik - Dev Lists wrote:
Costin Manolache wrote:
I'm not sure the security discussion is that simple, this seems
quite a
dangerous change.
Currently the user is restricted to the webapps/ directory
( well, he can
add a context
with the base in /etc an
Costin Manolache wrote:
I'm not sure the security discussion is that simple, this seems quite a
dangerous change.
Currently the user is restricted to the webapps/ directory ( well, he can
add a context
with the base in /etc and expose passwd I guess - but hopefully if a deploy
tool is used
or
I'm not sure the security discussion is that simple, this seems quite a
dangerous change.
Currently the user is restricted to the webapps/ directory ( well, he can
add a context
with the base in /etc and expose passwd I guess - but hopefully if a deploy
tool is used
or some automation is done on
The basic concept behind the logic is:
- Look for prefix
- Replace with new base path
The new path replacement is done before the symlink and case check is
done so those checks are still preserved. (Just with the new path alias).
If there is a security manager in play - it should already be bl
Remy Maucherat wrote:
It's not a real veto anyway, but no proper review mechanism exists at
the moment, and it's hard to integrate feature additions in 6.0.x
without prior discussion.
I did review the patch:
- the syntax seems appropriate
- I don't know if it allows redirecting a single fine,
Tim Funk wrote:
D'oh.
I was tempted to post a patch first and discuss, but since it was only a
setZZZ addition and the functionality is exactly the same when the
parameter is NOT set - I thought this could go CTR. In light of the
recent CTR/RTC discussions - we are still CTR until the vote pa
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: funkman
Date: Thu Sep 13 08:19:59 2007
New Revision: 575332
URL: http://svn.apache.org/viewvc?rev=575332&view=rev
Log:
Allow for Aliases at the resource level.
This is to prevent situations of relying on symlinks, or Filters
while still ma
D'oh.
I was tempted to post a patch first and discuss, but since it was only a
setZZZ addition and the functionality is exactly the same when the
parameter is NOT set - I thought this could go CTR. In light of the
recent CTR/RTC discussions - we are still CTR until the vote passes.
Likewise -
Peter Rossbach wrote:
Hi,
I like this FileDirContext extension. It is a very nice way to include
external content without symlinks!
I'm not hot about it, and this seems like a a sort of superset of the
customizable classloader (which I already didn't like much, if you're
following my idea).
Hi,
I like this FileDirContext extension. It is a very nice way to
include external content without symlinks!
Regards
Peter
Am 13.09.2007 um 17:25 schrieb Remy Maucherat:
[EMAIL PROTECTED] wrote:
Author: funkman
Date: Thu Sep 13 08:19:59 2007
New Revision: 575332
URL: http://svn.apache.
[EMAIL PROTECTED] wrote:
Author: funkman
Date: Thu Sep 13 08:19:59 2007
New Revision: 575332
URL: http://svn.apache.org/viewvc?rev=575332&view=rev
Log:
Allow for Aliases at the resource level.
This is to prevent situations of relying on symlinks, or Filters
while still make outside directorie
Author: funkman
Date: Thu Sep 13 08:19:59 2007
New Revision: 575332
URL: http://svn.apache.org/viewvc?rev=575332&view=rev
Log:
Allow for Aliases at the resource level.
This is to prevent situations of relying on symlinks, or Filters
while still make outside directories appear as part of the web
39 matches
Mail list logo
