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 not what is important,
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
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
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
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 little
Remy Maucherat wrote:
I tested with the security manager, and it doesn't behave correctly.
If the context.xml inside a webapp is:
Context
Resources className=org.apache.naming.resources.FileDirContext
docBase=c:/foo aliases=/mysecretpath/=c:/ /
/Context
The docBase hack
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)
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Author: funkman
Date: Thu Sep 13 08:19:59 2007
New Revision: 575332
URL: http://svn.apache.org/viewvc?rev=575332view=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
[EMAIL PROTECTED] wrote:
Author: funkman
Date: Thu Sep 13 08:19:59 2007
New Revision: 575332
URL: http://svn.apache.org/viewvc?rev=575332view=rev
Log:
Allow for Aliases at the resource level.
This is to prevent situations of relying on symlinks, or Filters
while still make outside
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:
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
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
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=575332view=rev
Log:
Allow for Aliases at the resource level.
This is to prevent situations of relying on symlinks, or Filters
while still
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
33 matches
Mail list logo
