QProcess Security and KSaveFile::rcsBackupFile()
awinterz at earthlink.net
Tue Feb 7 20:20:09 GMT 2006
On Tuesday 07 February 2006 14:54, Gregory Hayes wrote:
> I attached a patch that should implement the desired behavior. Please glance
> it over, before I commit.
Looks good to me Greg.
ksavefiletest still works too ;>
Go ahead and commit.
> RCS is available on Windows as well, to maintain cross platform
> compatibility will I need to search for "rcs.exe" in addition to "rcs", or
> will KStandardDirs::findExe("rcs") find both cases?
No idea. I don't think you are required to specify the ".exe" so we are probably ok.
> On 2/7/06, Martijn Klingens <klingens at kde.org> 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
> > > > specifies /usr/bin as the RCS default, but other platforms may pop it
> > > > a different part of the tree. Is there a way to just remove "." from
> > > > 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
> > doesn't allow arbitrary command execution per se, but it still seems like
> > needless security risk to me.
> > Why don't you pass the result of KStandardDirs::findExe instead of relying
> > on /usr/bin/env?
> > See
> > That also makes it somewhat more portable towards non-Unix platforms where
> > '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.)
> > --
> > Martijn
More information about the kde-core-devel