Process.Start() question

[stephen]

Hi,

I have an excel path white space/blank space in path issue.

I have to start an Excel application and I use System.Diagnostic.Process().
while testing I was hardcoding the values for e.g.

String testPath = @"""C:\Documents and Settings\User\My Documents\Excel
Files\Test.xls"""; and use this in the
System.Diagnostics.Process.Start("Excel.exe", testPath); it opens the excel
document

but when this path is recieved via a method, I have trouble appending the
@""" + testPath + """;
so that I can run this.

Please help!!!
Stephen

 

[Cowboy \(Gregory A. Beamer\)]

string test = "\"" + testPath + "\"";

--
Gregory A. Beamer
MCP: +I, SE, SD, DBA

*********************************************
| Think outside the box!
|
*********************************************

 

[Cowboy \(Gregory A. Beamer\)]

string test = "\"" + testPath + "\"";

--
Gregory A. Beamer
MCP: +I, SE, SD, DBA

*********************************************
| Think outside the box!
|
*********************************************

 

[Ben Voigt [C++ MVP]]

First suggestion: don't bother with the "Excel.exe". Just pass the
name of the document to the Process.Start() method. It will use the
Windows Shell to look up the associated application (Excel in this
case), and open the file with that application. Note that you
shouldn't need to put quotes around your filename as long as you pass
it as the filename for the single-argument Process.Start(String)
method.

While Windows will try reparsing at each possible token boundary, this opens
security holes because it prefers to break as early as possible.

So C:\Program Files\... means "C:\Program Files\..." unless someone put a
"C:\Program.exe" file on the computer.

Use the quotes to remove the ambiguity.

 

[Ben Voigt [C++ MVP]]

First suggestion: don't bother with the "Excel.exe". Just pass the
name of the document to the Process.Start() method. It will use the
Windows Shell to look up the associated application (Excel in this
case), and open the file with that application. Note that you
shouldn't need to put quotes around your filename as long as you pass
it as the filename for the single-argument Process.Start(String)
method.

While Windows will try reparsing at each possible token boundary, this opens
security holes because it prefers to break as early as possible.

So C:\Program Files\... means "C:\Program Files\..." unless someone put a
"C:\Program.exe" file on the computer.

Use the quotes to remove the ambiguity.

 

[stephen]

Hi Gregory,

Your suggestion worked.. Thanks for your help and yes, Peter will post my
code when I post a question.

Thanks,
Stephen

 

[stephen]

Hi Gregory,

Your suggestion worked.. Thanks for your help and yes, Peter will post my
code when I post a question.

Thanks,
Stephen

 

[Ben Voigt [C++ MVP]]

If the security issue is in fact a concern. I agree that the potential
for a problem exists, but the OP didn't say one way or the other whether
it would matter. And after all, if the computer is improperly configured
and someone can put a "program.exe" in the root directory, there's a
decent chance someone could simply replace "excel.exe" with the same
hostile program. Once an attacker has gotten far enough to copy
executables to arbitrary places on the hard drive, security has already
been compromised significantly.

Pete

I wanted to use short paths that would match the examples of this problem
that would be found on the 'NET.

The Excel spreadsheet most likely has a path such as:

C:\Documents and Settings\Clueless User\My Documents\This Month's
Project\forecast.xls

No unusual level of write access is needed to mess that up. A user with any
privilege level would be able to create a "C:\Documents and
Settings\Clueless User\My.exe" and in fact it's reasonably likely that a web
page might be able to drop such a nasty through a drive-by download on a
buggy browser.

 

[Ben Voigt [C++ MVP]]

If the security issue is in fact a concern. I agree that the potential
for a problem exists, but the OP didn't say one way or the other whether
it would matter. And after all, if the computer is improperly configured
and someone can put a "program.exe" in the root directory, there's a
decent chance someone could simply replace "excel.exe" with the same
hostile program. Once an attacker has gotten far enough to copy
executables to arbitrary places on the hard drive, security has already
been compromised significantly.

Pete

I wanted to use short paths that would match the examples of this problem
that would be found on the 'NET.

The Excel spreadsheet most likely has a path such as:

C:\Documents and Settings\Clueless User\My Documents\This Month's
Project\forecast.xls

No unusual level of write access is needed to mess that up. A user with any
privilege level would be able to create a "C:\Documents and
Settings\Clueless User\My.exe" and in fact it's reasonably likely that a web
page might be able to drop such a nasty through a drive-by download on a
buggy browser.

 

[Ben Voigt [C++ MVP]]

[...]
No unusual level of write access is needed to mess that up. A user with
any privilege level would be able to create a "C:\Documents and
Settings\Clueless User\My.exe" and in fact it's reasonably likely that a
web page might be able to drop such a nasty through a drive-by download
on a buggy browser.

It could. But why _would_ it? Just hoping that maybe a program might
stumble across it?

Whatever. I don't disagree the security issue exists. I simply disagree
that there's any reason to believe that in this specific example, it's a
concern. People writing a program for broad consumption should concern
themselves with it, but we have no reason to believe that's an issue here.

I don't believe in gratuitous introduction of security holes on the basis
that the application probably won't ever be used in a scenario where it
matters.

Unlike premature optimization, there's no such thing as premature security.
Either you secure from the beginning or you end up insecure, it's
practically impossible to tack on security afterward.

 

[Ben Voigt [C++ MVP]]

[...]
No unusual level of write access is needed to mess that up. A user with
any privilege level would be able to create a "C:\Documents and
Settings\Clueless User\My.exe" and in fact it's reasonably likely that a
web page might be able to drop such a nasty through a drive-by download
on a buggy browser.

It could. But why _would_ it? Just hoping that maybe a program might
stumble across it?

Whatever. I don't disagree the security issue exists. I simply disagree
that there's any reason to believe that in this specific example, it's a
concern. People writing a program for broad consumption should concern
themselves with it, but we have no reason to believe that's an issue here.

I don't believe in gratuitous introduction of security holes on the basis
that the application probably won't ever be used in a scenario where it
matters.

Unlike premature optimization, there's no such thing as premature security.
Either you secure from the beginning or you end up insecure, it's
practically impossible to tack on security afterward.