KShell & KMacroExpander - are we screwed?

[Oswald Buddenhagen]

On Sun, Oct 14, 2007 at 11:27:37PM +0200, Andreas Pakulat wrote:
> Ok, I read the mail, multiple times. But I still don't really
> understand the problems, I think.

> What I did understand is even if people use KShell::quoteargs and Co.
> for a given user-supplied command that should be executed via a shell,
> there's still the risk of executing something like rmdir c:\ if the
> environment of the user gets prepared properly? 
> 
well, in fact, you understood the problem pretty well. ;)

> On 05.10.07 15:52:01, Oswald Buddenhagen wrote:
> > possible solutions:
> > - ignore the problem.
> > - ban % from arguments.
> > - screw cmd, v1: kprocess::setshellcommand is nuked again
> > - screw cmd, v2: use a posix shell under windows
> > 
> > unless somebody has a better idea, i vote for screw cmd v2, and as a
> > last resort v1 for windows only.
> 
> Well, I'm tempted to say: go for option 1 on win32. I mean if you manage
> to get your environment screwed up who knows what else goes on on that
> machine, it needs a reinstall anyway.
> 
that's oversimplifying the matter.
- you might not need to crack the system to change the env. the
  application might contain some bug that prods it into setenv()ing
  something silly.
- while the potential security problem is the biggest one, it is not the
  only one. one might get an expansion completely unexpectedly. ok, so
  this is unprobable, but still not impossible (i guess when you get
  something like that on the command line or in a batch script, you'll
  be pretty confused as to wtf happened in the first place).
- the "caret-stuffing" to get it even halfways safe (but not secure) is
  fugly. :}

> If thats not an option I think I vote for screw v1.
>
well, if this makes win devels happy ...
but don't expect any unix devels to be considerate with your cripled
platform.

> screw v2 is still not an option,
> it doesn't make anything simpler for win32 kde developers
>
well, it does by not requiring them to do any porting in some cases.

> and especially not for the users. Those users would have to adopt the
> commands and arguments to posix shell, which you can't really expect
> from them.
> 
you should consider that about 99% of the commands the user ever
supplies will look like "foo %f", etc.  it only becomes a problem if
somebody tries to execute complex shell constructs. but those able to do
that are also able to learn the posix equivalents (it's not like cmd has
a lot of stuff one needs to learn a replacement for :-P) and might even
appreciate the considerably less braindead syntax rules. ;)
btw, i wouldn't go for bash as the posix shell - ash is much leaner -
provided it runs with, e.g. mingw.
why exactly is a cygwin-based shell is a no-go? ash + libc.dll +
cygwin.dll (or whatever that might be in the end) isn't really a heavy
set of deps.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.