Solved Question about QProcess and deleting a file
-
@VRonin
Unfortunately not :( While I might be prepared to use this approach, my end users are not. They won't have/create the file, they won't be prepared to run the configurer, and they generally will not accept or cooperate.I knew about this avenue, and I do respect your suggestion, but the purpose of this question is to emulate just what MySQL Workbench does (as I've shown above) in precisely the same circumstances, i.e. no
.mylogin.cnf
file at all, let alone encrypted. -
I think this might be more secure but I'm not 100% sure. You could use QProcessEnvironment to assign your password to the
MYSQL_PWD
environment variable. -
@mchinand
Ooohhh, that's interesting. Where do you get theMYSQL_PWD
environment variable documentation from, please? -
@JNBarchan said in Question about QProcess and deleting a file:
@mchinand
Ooohhh, that's interesting. Where do you get theMYSQL_PWD
environment variable documentation from, please?See this part of the QProcess help. Your mysqldump process will use the value of MYSQL_PWD for the password if you don't specify it as a command-line argument. After further searching, it's probably not any more secure since there are ways to get a process' environment according to the MySQL manual (bottom of that page)
-
@mchinand
I looked at the MySQL manual page, thanks. It was a good idea I didn't know about, and is useful information. Unfortunately, though, it actually describes environment variable as "extremely insecure", one rank down from passing on OS command-line, so probably not. But a good suggestion! -
@JNBarchan
But on the practical side, using MYSQL_PWD remove the race condition on when to remove the file. ?Also, if you had a small launcher app, that you run from the master
GUI, that fires up and starts mysqldump and then terminates, would that not remove the environment and MYSQL_PWD in a very short time frame, making the user ability to list the password using ps way slimmer?Mind you im comparing this with a text file with a plain password that will exit for a second or longer. ( to be on safe side)
I mean, a file not hidden from lsof either and if the user have root access, both approaches are equally easy to hax.
I assume you will be using a read only user account for backup.
-
But on the practical side, using MYSQL_PWD remove the race condition on when to remove the file. ?
Yes, but then so would passing
--password=...
on the command-line.Also, if you had a small launcher app, that you run from the master
GUI, that fires up and starts mysqldump and then terminates, would that not remove the environment and MYSQL_PWD in a very short time frame, making the user ability to list the password using ps way slimmer?For the record, no. Because it's using an environment variable passed to the
mysqldump
executable, it persists in that process's space for the duration, and can be found viaps
. In that sense, the command-line argument is actually safer, becausemysqldump
obscures this immediately after start up.I assume you will be using a read only user account for backup.
Umm, no actually. Credentials for MySQL are configured into my app from someone at user's site. Chances are, they only even have one account, and that account may well be the
root
one, wouldn't have another one for writing to the database let alone reading from it.... Don't shoot me, I'm only the messenger. -
@JNBarchan
Oh, i though the environment would die with the calling process.
Yep then clearly it's worse. ( as backup takes comparatively long time)Are you in control of the mysqldump ?
I wondering if a user could simply replace the mysqldump executable with own program and be served the password. -
@mrjj
Child processes inherit their own copy of parent/caller's environment, else whenever parent exited without waiting for child to complete child would suddenly lose its environment variables!Theoretically at least, end user cannot use his own
mysqldump
program because full path can be configured into my app by their administrator.These choices have already been made by MySQL Workbench when it invokes
mysqldump
. And that has decided to pass password via temporary file. I'm just trying to emulate similar behaviour from Qt, in safest fashion I can think of. -
@JNBarchan
Yeah that makes sense. I was thinking in terms of the Qt Class but of course child has to keep a copy.Ok so at least it is a bit locked down :)
-
Another option that I think will work (and more secure) is to use the command-line option "-p" alone without the password. In this case, it normally prompts the user for the password. You should be able to do a
process->write("yourpassword\n");
after starting the process. I'm not sure if you'll need to add a short delay between
start()
and thiswrite
or not. No temporary file containing the password, no password on the command-line, no password in environment variables. -
@mchinand
Ah, now that is interesting indeed. I shall give it a try and report back.... -
@mchinand , and others
Firstly, @mchinand your
QProcess:write(password)
does indeed work, just wanted to say that.After weighing up
--password
command-line,--defaults-file
temporary-file command-line,~/mylogin.cnf
(with & without encryption) andQProcess:write
, I have actually finally come down on the side of @mchinand'sMYSQL_PWD
environment variable suggestion. They all have pros & cons, but for various reasons (which I'll explain only if you're truly interested!) the environment variable passing suits my code the best and is simplest.For anyone who cares, my pattern is now:
self.process = QProcess() env = self.process.processEnvironment() env.insert("MYSQL_PWD", password) self.process.setProcessEnvironment(env) self.process.start("{} {}".format(program, args))
Note how the way it works from Qt is that you don't put the environment variable into parent process's own environment for inheritance to child, you put it into
QProcess
's environment for the child process only. Which suits me --- no need to remove it from my own environment after starting sub-process.