Stephen and Archie
Stephen Woods wrote:
Good point... I didn't even consider that the existing allowable tasks
were already unsafe....
On Mon, Mar 23, 2009 at 12:55 PM, Archie Cobbs <[email protected]> wrote:
Oops, sorry I missed the last sentence of your email.
You are right. What's required however is some kind of security policy and
for each ant task we should allow, a security analysis of whether it is
considered "safe" or not.
Just leaping in here... Is it the responsibility of a library API (which
is what Ivy is) to decide on the appropriate security policy of the
application
calling it. Java has a very sophisticated security policy mechanism. For
example, with a few lines in a security descriptor you can restrict
write access to
specific areas in the filing system. Wouldn't it be better to try and
use the tools already in the language? In the example below you could
easily write
policy which didn't allow the packager application to overwrite specific
files.
Apologies if this is missing the point - I just thought I'd raise it.
Regards
Alan Chaney
For example, the <javadoc> task creates a bunch of files. What if someone
configured it to write these files to /srv/www (or whatever your document
root is) so that it overwrote your existing index.html? Etc.
A larger issue is that the tasks that we currently do allow in "safe" mode
are already questionably "safe". E.g., <move> and <copy> are already
perfectly capable of obliterating any sensitive files you may have.
So, it's worth thinking about the big picture. E.g., at one point I
suggested getting rid of "safe" mode (because it's not really safe) and have
things always work in "unrestricted" mode. But other folks didn't like that
idea -- with good reason.
In the short term, it's reasonable to suggest that since <javadoc> is no
less safe than <move> or <copy> then it should be included as well. But
before we go through each and every ant task maybe we should think about
whether "safe" mode is really useful.
-Archie
On Mon, Mar 23, 2009 at 11:45 AM, Stephen Woods <[email protected]> wrote:
Well, yeah... I know that you can just set restricted="false" - I said
as much. But this opens the flood gates for all kinds of malicious
behavior. As far as I know, javadoc should be safe enough to run in
restricted mode.
It would be nice to be able to run javadoc _without_ having to set
restricted to "false".
On Mon, Mar 23, 2009 at 9:15 AM, Archie Cobbs <[email protected]>
wrote:
You can do this already. You just have to set restricted="false" in your
configuration of the packager resolver. Documentation is
here<
http://ant.apache.org/ivy/history/latest-milestone/resolver/packager.html>
.
-Archie
On Sun, Mar 22, 2009 at 2:28 PM, Stephen Woods <[email protected]>
wrote:
The packager resolver limits the types of ant commands a packager uses
to build its appropriate artifacts. Many of the source distributions
do not bundle pre-generated javadoc, but they do bundle source. It
would be nice to be able to run the javadoc ant task during the
packaging process in order to make javadoc artifacts without needing
to set the restricted attribute to "false". Is it even possible to
compromise a system by running javadoc?
Just a thought for future ivy releases...
--
Archie L. Cobbs
--
Archie L. Cobbs
!DSPAM:49c7c630245372051017194!
