QProcess Security and KSaveFile::rcsBackupFile()

Nicolas Goutte nicolasg at snafu.de
Tue Feb 7 17:14:29 GMT 2006


On Tuesday 07 February 2006 17:34, Martijn Klingens wrote:
> On Friday 03 February 2006 02:05, Allen Winter wrote:
> > On Thursday 02 February 2006 04:02, Gregory Hayes wrote:
> > > That is a good point, I didn't think of the path issue! I believe the
> > > LSB specifies /usr/bin as the RCS default, but other platforms may pop
> > > it in a different part of the tree. Is there a way to just remove "."
> > > from the QProcess $PATH? If not I would suggest
> > > "/bin:/usr/bin:/usr/local/bin" (but someone could be creative and stick
> > > it in /opt/rcs-5.7/bin or something). RCS is likely "rcs.exe" on
> > > Windows too, so we may need to massage that as well (if it matters to
> > > QProcess).
> >
> > I just committed a change that uses the $PATH you suggest.
>
> That runs shell commands though. As long as qFilename is properly quoted it
> doesn't allow arbitrary command execution per se, but it still seems like a
> needless security risk to me.
>
> Why don't you pass the result of KStandardDirs::findExe instead of relying
> on /usr/bin/env?
>
> See
>
> http://developer.kde.org/documentation/library/cvs-api/kdelibs-apidocs/kdec
>ore/html/classKStandardDirs.html#e1
>
> That also makes it somewhat more portable towards non-Unix platforms where
> the 'VAR=value cmd --args' style of invocation is often unavailable. (Not
> to mention that /usr/bin/env is often unavailable, but so is rcs probably
> as well, making this possibly a moot point.)

And when you use /usr/bin/env you cannot give any parameter to the application 
called by env (for example at least some Linux 2.4.x cannot do it.)

Have a nice day!





More information about the kde-core-devel mailing list