You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Jim Lerner <jl...@genome.wi.mit.edu> on 2003/01/30 21:10:51 UTC
Axis attachment naming enhancement (code attached)
I am submitting for your approval (and integration) changes to
Axis-1_1beta that allows Axis to create unique names for file
attachments that bear a passing resemblance to the original filename.
This is critical for applications that use the filename [extension] for
disambiguation, and also in the case of multiple attachments on a single
message. It's my understanding that there are a number of Axis users
out there who have suffered for lack of a solution to this problem.
The premise is simple: add a MIME header to each attachment with the
original filename. When the file is sent to Axis, Axis'
ManagedMemoryDataSource will use this name to create a uniquely named
temporary file (eg. Axis98765_myfile.xls) rather than the usual
(Axis98765axis). Likewise, when Axis receives a file to be sent back to
the caller, a MIME header on the attachment indicates the original name
(Axis98765_myfile.xls). This is not quite optimal, but it is easy
enough for the client to parse and use, given that the underscore is
guaranteed to be the first one in the filename. Existing applications
that don't set the MIME header will continue to see the previous file
naming behavior.
The changes that I've made (in the attached files) are as follows:
org/apache/axis/transport/http/HTTPConstants:
added HEADER_X_ORIGINAL_FILENAME for new MIME header
org/apache/axis/attachments/AttachmentPart:
setMimeHeader(DataSource's getName()) when creating an attachment part
from a DataHandler and
when setting a DataHandler for an existing AttachmentPart.
org/apache/axis/attachments/MultiPartRelatedInputStream:
inform ManagedMemoryDataSource of the X_ORIGINAL_FILENAME MIME heading.
org/apache/axis/attachments/ManagedMemoryDataSource:
added new constructor with extra parameter for original name (other
constructors use this(..., null))
added storage for the original filename
use the original name when constructing the temporary file into which
the in-memory file is flushed.
Please let me know if you need any further clarification, any of this
needs to be reworked, etc. I'm hoping that you'll find this to be
useful, correct, and worth integrating into the CVS repository.
- Jim
Re: Axis attachment naming enhancement (code attached)
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Jim Lerner" <jl...@genome.wi.mit.edu>
To: <ax...@xml.apache.org>
Sent: Thursday, January 30, 2003 12:10
Subject: Axis attachment naming enhancement (code attached)
>
> The premise is simple: add a MIME header to each attachment with the
> original filename. When the file is sent to Axis, Axis'
> ManagedMemoryDataSource will use this name to create a uniquely named
> temporary file (eg. Axis98765_myfile.xls) rather than the usual
> (Axis98765axis). Likewise, when Axis receives a file to be sent back to
> the caller, a MIME header on the attachment indicates the original name
> (Axis98765_myfile.xls). This is not quite optimal, but it is easy
> enough for the client to parse and use, given that the underscore is
> guaranteed to be the first one in the filename. Existing applications
> that don't set the MIME header will continue to see the previous file
> naming behavior.
I too have encountered this problem, which I fixed in my service API by
making people add the filename, or at least the extension thereof as part of
a separate array parameter. An ugly hack, but one which works across
platforms, meaning .NET sending DIME messages still works.
>
> The changes that I've made (in the attached files) are as follows:
First, we celebrate code enhancements, be we celebrate them more as CVS
diffs, so it is easier to see what has changed and to merge those changes
across versions.
I should also add that AttachmentPart and some of the other files underwent
mild change last weekend, to the extent that you can now ask an
AttachmentPart for its filename (may be null), and detach the part from the
filename so that when the AttachmentPart is finalized, the file that was
uploaded is retained. That solved my more pressing problem, how to stop
copying and leaking 30MB files, but also means that diffs against latest CVS
are preferable.
1. I like the idea of sending some extra path information on attachments,
though for security/privacy we'd need to be sure the caller wasnt leaking
too much information. Should only the extension go? Or the
filename+extension, ignoring the directories? I would prefer either of those
to the full path. Of course, this is dependent on what DataSource.getName()
implementationss return.
2. I also think that with the stuff that went in at the weekend, there is no
need to save the received file with the original name (remember, we dont
always save stuff), but could just make the mime header available to the
recipient, who can get the file and rename it if they want. or save the in
memory datastream to a file of the appropriate name too.
3. Interop worries me. If you code your server expecting this header, you
cant handle any caller other than Axis. This doesnt mean we cant or shouldnt
add the filename, just that it is dangerously non-standard, and the server
cannot rely on it. Ugly explicit extra parameter hacks like what I used, may
be the currently workable solution.
I also dont like the way we are effectively forcing all files to disk before
sending; that is not needed -but a consequence of calling getName(). [This
is maybe a fault of ManagedMemoryDataSource.getName()]
Overall then, I agree with you on the need to get some source file
information, but I dont like the adverse consequences of this
implementation: always saving files; having to add a new constructor to
ManagedMemoryDataSource; a non-standard header leading to interop problems.
The first is an implementation detail, the last more troublesome.
I might bounce this past the soapbuilders, a little quirk on attachments,
specifically the need to somehow retain a bit of file name info. But I dont
think we need to put this in axis as it stands, yet. It can be done on a
case by case basis in custom apps by
-adding the header manually
-getting the header manually
-getting the current filename of the attachment and moving/renaming it.
This adds extra dev work, but at least makes the interop issue explicit. If
one web service does something automatically, people just assume it works
everywhere.
Thoughts?
-Steve
Re: Axis attachment naming enhancement (code attached)
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Jim Lerner" <jl...@genome.wi.mit.edu>
To: <ax...@xml.apache.org>
Sent: Thursday, January 30, 2003 14:24
Subject: Re: Axis attachment naming enhancement (code attached)
> Since Axis is already willing to hand me the file (on the server or the
> client) with a name like "/tmp/Axis56789axis", I am able to do with it
> what I will. That means that if I wanted to rename it and possibly
> execute it, I could. What difference does it make to Axis or system
> security if the original filename/extension are preserved? The danger
> is no greater. It seems to me that security has to be implemented for
> any Axis service that cares about it, but that obfuscating the filename
> does not serve that purpose.
what if I was malicious and sent you a file with the header set to
../../../etc/passwd
You might prepend /tmp/axis/axis123_ to it, but the file system might still
resolve the .. elements and stamp on your password file
Re: Axis attachment naming enhancement (code attached)
Posted by Jim Lerner <jl...@genome.wi.mit.edu>.
Since Axis is already willing to hand me the file (on the server or the
client) with a name like "/tmp/Axis56789axis", I am able to do with it
what I will. That means that if I wanted to rename it and possibly
execute it, I could. What difference does it make to Axis or system
security if the original filename/extension are preserved? The danger
is no greater. It seems to me that security has to be implemented for
any Axis service that cares about it, but that obfuscating the filename
does not serve that purpose.
- Jim
James M Snell wrote:
>I would think that allowing the client to control the naming of the files
>saved on the server would constitute a security risk on the server. If
>the attachment contains a malicious executable, then Axis would be
>unwittingly allowing the code to be saved to the server in a form that
>would allow it to be easily executed (e.g. tempfilename.exe). While I
>recognize the benefits that something like this would allow, I do not
>believe that this is the right solution.
>
>- James Snell
> IBM Emerging Technologies
> jasnell@us.ibm.com
> (559) 587-1233 (office)
> (700) 544-9035 (t/l)
> Programming Web Services With SOAP
> O'Reilly & Associates, ISBN 0596000952
>
> Have I not commanded you? Be strong and courageous.
> Do not be terrified, do not be discouraged, for the Lord your
> God will be with you whereever you go. - Joshua 1:9
>
>
>
>Jim Lerner <jl...@genome.wi.mit.edu>
>01/30/2003 12:10 PM
>Please respond to axis-dev
>
>
>To
>axis-dev@xml.apache.org
>cc
>
>bcc
>
>Subject
>Axis attachment naming enhancement (code attached)
>
>
>
>
>
>I am submitting for your approval (and integration) changes to
>Axis-1_1beta that allows Axis to create unique names for file
>attachments that bear a passing resemblance to the original filename.
>This is critical for applications that use the filename [extension] for
>disambiguation, and also in the case of multiple attachments on a single
>message. It's my understanding that there are a number of Axis users
>out there who have suffered for lack of a solution to this problem.
>
>The premise is simple: add a MIME header to each attachment with the
>original filename. When the file is sent to Axis, Axis'
>ManagedMemoryDataSource will use this name to create a uniquely named
>temporary file (eg. Axis98765_myfile.xls) rather than the usual
>(Axis98765axis). Likewise, when Axis receives a file to be sent back to
>the caller, a MIME header on the attachment indicates the original name
>(Axis98765_myfile.xls). This is not quite optimal, but it is easy
>enough for the client to parse and use, given that the underscore is
>guaranteed to be the first one in the filename. Existing applications
>that don't set the MIME header will continue to see the previous file
>naming behavior.
>
>The changes that I've made (in the attached files) are as follows:
>
>org/apache/axis/transport/http/HTTPConstants:
>added HEADER_X_ORIGINAL_FILENAME for new MIME header
>
>org/apache/axis/attachments/AttachmentPart:
>setMimeHeader(DataSource's getName()) when creating an attachment part
>from a DataHandler and
>when setting a DataHandler for an existing AttachmentPart.
>
>org/apache/axis/attachments/MultiPartRelatedInputStream:
>inform ManagedMemoryDataSource of the X_ORIGINAL_FILENAME MIME heading.
>
>org/apache/axis/attachments/ManagedMemoryDataSource:
>added new constructor with extra parameter for original name (other
>constructors use this(..., null))
>added storage for the original filename
>use the original name when constructing the temporary file into which
>the in-memory file is flushed.
>
>Please let me know if you need any further clarification, any of this
>needs to be reworked, etc. I'm hoping that you'll find this to be
>useful, correct, and worth integrating into the CVS repository.
>
>- Jim
>
>
>
>
>
>
>
>
>
Re: Axis attachment naming enhancement (code attached)
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "James M Snell" <ja...@us.ibm.com>
To: <ax...@xml.apache.org>
Sent: Thursday, January 30, 2003 14:21
Subject: Re: Axis attachment naming enhancement (code attached)
> +1. some kind of metadata is needed.
>> Perhaps the real solution is to make Axis store the filename somewhere.
>> (perhaps in a file like Axis98765axis.properties)? I agree that letting
>> the client control the server filename is a security risks, but carrying
>> meta-data, such as whether or not the file is a .exe file) is useful.
well, if the sender sets the filename as a a mime header, the header
magically becomes a piece of metadata at the far end -a header element.
So if we add a method in AttachmentPart to add the filename as a header
(yes, something you call by hand), we could provide the code to get the
filename something lke
string filename=null;
if(datasource instanceof ManagedMemoryDataSource) {
... filename=getDiskCacheFilename();
} else {
filename=datasource.getName();
}
if(filename!=null) {
filename= (extract filename and extension from path)
addHeader(X_ORIGINAL_FILENAME,filename);
}
so only add the header if we have a filename (no forced save to disk), and
only do the work if the user explicitly requests it.
Re: Axis attachment naming enhancement (code attached)
Posted by James M Snell <ja...@us.ibm.com>.
+1. some kind of metadata is needed.
- James Snell
IBM Emerging Technologies
jasnell@us.ibm.com
(559) 587-1233 (office)
(700) 544-9035 (t/l)
Programming Web Services With SOAP
O'Reilly & Associates, ISBN 0596000952
Have I not commanded you? Be strong and courageous.
Do not be terrified, do not be discouraged, for the Lord your
God will be with you whereever you go. - Joshua 1:9
Jess Sightler <js...@eximtechnologies.com>
01/30/2003 02:00 PM
Please respond to axis-dev
To
axis-dev@xml.apache.org
cc
bcc
Subject
Re: Axis attachment naming enhancement (code attached)
Perhaps the real solution is to make Axis store the filename somewhere
(perhaps in a file like Axis98765axis.properties)? I agree that letting
the client control the server filename is a security risks, but carrying
meta-data, such as whether or not the file is a .exe file) is useful.
On Thu, 2003-01-30 at 16:43, James M Snell wrote:
> I would think that allowing the client to control the naming of the
files
> saved on the server would constitute a security risk on the server. If
> the attachment contains a malicious executable, then Axis would be
> unwittingly allowing the code to be saved to the server in a form that
> would allow it to be easily executed (e.g. tempfilename.exe). While I
> recognize the benefits that something like this would allow, I do not
> believe that this is the right solution.
>
> - James Snell
> IBM Emerging Technologies
> jasnell@us.ibm.com
> (559) 587-1233 (office)
> (700) 544-9035 (t/l)
> Programming Web Services With SOAP
> O'Reilly & Associates, ISBN 0596000952
>
> Have I not commanded you? Be strong and courageous.
> Do not be terrified, do not be discouraged, for the Lord your
> God will be with you whereever you go. - Joshua 1:9
>
>
>
> Jim Lerner <jl...@genome.wi.mit.edu>
> 01/30/2003 12:10 PM
> Please respond to axis-dev
>
>
> To
> axis-dev@xml.apache.org
> cc
>
> bcc
>
> Subject
> Axis attachment naming enhancement (code attached)
>
>
>
>
>
> I am submitting for your approval (and integration) changes to
> Axis-1_1beta that allows Axis to create unique names for file
> attachments that bear a passing resemblance to the original filename.
> This is critical for applications that use the filename [extension] for
> disambiguation, and also in the case of multiple attachments on a single
> message. It's my understanding that there are a number of Axis users
> out there who have suffered for lack of a solution to this problem.
>
> The premise is simple: add a MIME header to each attachment with the
> original filename. When the file is sent to Axis, Axis'
> ManagedMemoryDataSource will use this name to create a uniquely named
> temporary file (eg. Axis98765_myfile.xls) rather than the usual
> (Axis98765axis). Likewise, when Axis receives a file to be sent back to
> the caller, a MIME header on the attachment indicates the original name
> (Axis98765_myfile.xls). This is not quite optimal, but it is easy
> enough for the client to parse and use, given that the underscore is
> guaranteed to be the first one in the filename. Existing applications
> that don't set the MIME header will continue to see the previous file
> naming behavior.
>
> The changes that I've made (in the attached files) are as follows:
>
> org/apache/axis/transport/http/HTTPConstants:
> added HEADER_X_ORIGINAL_FILENAME for new MIME header
>
> org/apache/axis/attachments/AttachmentPart:
> setMimeHeader(DataSource's getName()) when creating an attachment part
> from a DataHandler and
> when setting a DataHandler for an existing AttachmentPart.
>
> org/apache/axis/attachments/MultiPartRelatedInputStream:
> inform ManagedMemoryDataSource of the X_ORIGINAL_FILENAME MIME heading.
>
> org/apache/axis/attachments/ManagedMemoryDataSource:
> added new constructor with extra parameter for original name (other
> constructors use this(..., null))
> added storage for the original filename
> use the original name when constructing the temporary file into which
> the in-memory file is flushed.
>
> Please let me know if you need any further clarification, any of this
> needs to be reworked, etc. I'm hoping that you'll find this to be
> useful, correct, and worth integrating into the CVS repository.
>
> - Jim
>
>
>
>
>
>
>
--
=======================================
Jess Sightler
Senior Developer
Exim Technologies
131 Falls Street
Greenville SC 29601
Phone: 864-679-4651
=======================================
Re: Axis attachment naming enhancement (code attached)
Posted by Jess Sightler <js...@eximtechnologies.com>.
Perhaps the real solution is to make Axis store the filename somewhere
(perhaps in a file like Axis98765axis.properties)? I agree that letting
the client control the server filename is a security risks, but carrying
meta-data, such as whether or not the file is a .exe file) is useful.
On Thu, 2003-01-30 at 16:43, James M Snell wrote:
> I would think that allowing the client to control the naming of the files
> saved on the server would constitute a security risk on the server. If
> the attachment contains a malicious executable, then Axis would be
> unwittingly allowing the code to be saved to the server in a form that
> would allow it to be easily executed (e.g. tempfilename.exe). While I
> recognize the benefits that something like this would allow, I do not
> believe that this is the right solution.
>
> - James Snell
> IBM Emerging Technologies
> jasnell@us.ibm.com
> (559) 587-1233 (office)
> (700) 544-9035 (t/l)
> Programming Web Services With SOAP
> O'Reilly & Associates, ISBN 0596000952
>
> Have I not commanded you? Be strong and courageous.
> Do not be terrified, do not be discouraged, for the Lord your
> God will be with you whereever you go. - Joshua 1:9
>
>
>
> Jim Lerner <jl...@genome.wi.mit.edu>
> 01/30/2003 12:10 PM
> Please respond to axis-dev
>
>
> To
> axis-dev@xml.apache.org
> cc
>
> bcc
>
> Subject
> Axis attachment naming enhancement (code attached)
>
>
>
>
>
> I am submitting for your approval (and integration) changes to
> Axis-1_1beta that allows Axis to create unique names for file
> attachments that bear a passing resemblance to the original filename.
> This is critical for applications that use the filename [extension] for
> disambiguation, and also in the case of multiple attachments on a single
> message. It's my understanding that there are a number of Axis users
> out there who have suffered for lack of a solution to this problem.
>
> The premise is simple: add a MIME header to each attachment with the
> original filename. When the file is sent to Axis, Axis'
> ManagedMemoryDataSource will use this name to create a uniquely named
> temporary file (eg. Axis98765_myfile.xls) rather than the usual
> (Axis98765axis). Likewise, when Axis receives a file to be sent back to
> the caller, a MIME header on the attachment indicates the original name
> (Axis98765_myfile.xls). This is not quite optimal, but it is easy
> enough for the client to parse and use, given that the underscore is
> guaranteed to be the first one in the filename. Existing applications
> that don't set the MIME header will continue to see the previous file
> naming behavior.
>
> The changes that I've made (in the attached files) are as follows:
>
> org/apache/axis/transport/http/HTTPConstants:
> added HEADER_X_ORIGINAL_FILENAME for new MIME header
>
> org/apache/axis/attachments/AttachmentPart:
> setMimeHeader(DataSource's getName()) when creating an attachment part
> from a DataHandler and
> when setting a DataHandler for an existing AttachmentPart.
>
> org/apache/axis/attachments/MultiPartRelatedInputStream:
> inform ManagedMemoryDataSource of the X_ORIGINAL_FILENAME MIME heading.
>
> org/apache/axis/attachments/ManagedMemoryDataSource:
> added new constructor with extra parameter for original name (other
> constructors use this(..., null))
> added storage for the original filename
> use the original name when constructing the temporary file into which
> the in-memory file is flushed.
>
> Please let me know if you need any further clarification, any of this
> needs to be reworked, etc. I'm hoping that you'll find this to be
> useful, correct, and worth integrating into the CVS repository.
>
> - Jim
>
>
>
>
>
>
>
--
=======================================
Jess Sightler
Senior Developer
Exim Technologies
131 Falls Street
Greenville SC 29601
Phone: 864-679-4651
=======================================
Re: Axis attachment naming enhancement (code attached)
Posted by James M Snell <ja...@us.ibm.com>.
I would think that allowing the client to control the naming of the files
saved on the server would constitute a security risk on the server. If
the attachment contains a malicious executable, then Axis would be
unwittingly allowing the code to be saved to the server in a form that
would allow it to be easily executed (e.g. tempfilename.exe). While I
recognize the benefits that something like this would allow, I do not
believe that this is the right solution.
- James Snell
IBM Emerging Technologies
jasnell@us.ibm.com
(559) 587-1233 (office)
(700) 544-9035 (t/l)
Programming Web Services With SOAP
O'Reilly & Associates, ISBN 0596000952
Have I not commanded you? Be strong and courageous.
Do not be terrified, do not be discouraged, for the Lord your
God will be with you whereever you go. - Joshua 1:9
Jim Lerner <jl...@genome.wi.mit.edu>
01/30/2003 12:10 PM
Please respond to axis-dev
To
axis-dev@xml.apache.org
cc
bcc
Subject
Axis attachment naming enhancement (code attached)
I am submitting for your approval (and integration) changes to
Axis-1_1beta that allows Axis to create unique names for file
attachments that bear a passing resemblance to the original filename.
This is critical for applications that use the filename [extension] for
disambiguation, and also in the case of multiple attachments on a single
message. It's my understanding that there are a number of Axis users
out there who have suffered for lack of a solution to this problem.
The premise is simple: add a MIME header to each attachment with the
original filename. When the file is sent to Axis, Axis'
ManagedMemoryDataSource will use this name to create a uniquely named
temporary file (eg. Axis98765_myfile.xls) rather than the usual
(Axis98765axis). Likewise, when Axis receives a file to be sent back to
the caller, a MIME header on the attachment indicates the original name
(Axis98765_myfile.xls). This is not quite optimal, but it is easy
enough for the client to parse and use, given that the underscore is
guaranteed to be the first one in the filename. Existing applications
that don't set the MIME header will continue to see the previous file
naming behavior.
The changes that I've made (in the attached files) are as follows:
org/apache/axis/transport/http/HTTPConstants:
added HEADER_X_ORIGINAL_FILENAME for new MIME header
org/apache/axis/attachments/AttachmentPart:
setMimeHeader(DataSource's getName()) when creating an attachment part
from a DataHandler and
when setting a DataHandler for an existing AttachmentPart.
org/apache/axis/attachments/MultiPartRelatedInputStream:
inform ManagedMemoryDataSource of the X_ORIGINAL_FILENAME MIME heading.
org/apache/axis/attachments/ManagedMemoryDataSource:
added new constructor with extra parameter for original name (other
constructors use this(..., null))
added storage for the original filename
use the original name when constructing the temporary file into which
the in-memory file is flushed.
Please let me know if you need any further clarification, any of this
needs to be reworked, etc. I'm hoping that you'll find this to be
useful, correct, and worth integrating into the CVS repository.
- Jim