Question about QProcess and deleting a file

mrjj

Hi
I think
http://doc.qt.io/qt-5/qtemporaryfile.html
will auto delete as soon as QTemporaryFile instance is.

mrjj

@JNBarchan
Oh, i mean what OS command are you calling/running ?

JonB

Oh, i mean what OS command are you calling/running ?

? I develop under Linux (only). Users could be running either Linux or Windows. Solution will work for whatever it works for. If it doesn't work under Windoze that's their fault for running a crappy OS. If if doesn't work under Linux I won't be able to test it, and won't be happy!

JonB

@mrjj said in Question about QProcess and deleting a file:

Hi
I think
http://doc.qt.io/qt-5/qtemporaryfile.html
will auto delete as soon as QTemporaryFile instance is.

Yes, thank you. It says:

QTemporaryFile is used to create unique temporary files safely. The file itself is created by calling open(). The name of the temporary file is guaranteed to be unique (i.e., you are guaranteed to not overwrite an existing file), and the file will subsequently be removed upon destruction of the QTemporaryFile object

This is better than nothing. However because it doesn't say whether it uses a native OS facility (if available) for this, if it just implements in its own code that won't help if parent Qt program dies without cleaning up. And I really don't want to leave an external file with a password in it lying around in the file system potentially....

VRonin

QTemporaryFile (if not leaked) guarantees the file is removed when the program closes (unless you explicitly tell it not to delete it). The problem with it is that if the program crashes or gets killed that file will still live. That's why I suggest managing the life of the file in a separate, very simple program that has very limited chance to crash.

When I use QTemporaryFile I also always set up a function like this that removes any leftover temporary file from a previous crash and call it at startup

Edit:

I really don't want to leave an external file with a password in it lying around in the file system potentially....

I don't think you can ever guarantee this.

Edit2:
If security is really a concern then you'd need to even prevent recovery of the file and this is basically impossible on SSD.
I think you are concerned about security while a fatal security flaw was introduced by something you have no control over. If you have to live with the vulnerability, roll with it

JonB

@VRonin
Yeah OK.

I've started to look up what i had in mind. Here's Linux man open(2):

   O_TMPFILE (since Linux 3.11)
         Create  an unnamed temporary file.  The pathname argument specifies a directory; an unnamed  inode  will  be  created  in  that
         directory's  filesystem.  Anything written to the resulting file
         will be lost when the last file descriptor is closed, unless the
         file is given a name.

That's what I had in mind, because you'll see it doesn't matter if the creating process dies. But I just realised this gives the file no name, so it won't be so useful for passing to another program!!

OK, so man 3 tmpfile:

   The  tmpfile()  function  opens  a  unique  temporary  file  in  binary
  read/write (w+b) mode.  The file will be automatically deleted when  it
  is closed or the program terminates.

This does create a named file, and returns an open handle. Again note the "deleted when program terminates" (assuming it's an OS facility, if they only mean C runtime clean-up it's no good... I need to check, sigh.). I think this is the closest to what I recall...

As I said, I'm not fanatical over security, I know it will vulnerable, just looking for a reasonable deal.

JonB

OK, I guess I'll have to reveal what this subprocess is!

mysqldump, to do database backups. It needs username + password to connect to MySQL server as.

If you look at how MySQL Workbench invokes it, it uses mysqldump's acceptance of command-line:

mysqldump --defaults-file="/tmp/tmpsYWm9r/extraparams.cnf" ...

to pass (just) the password in that file. I do not know what flags it might use to open that file.

Now, at present I am just using command-line:

mysqldump --user=... --password=... ...

The output --- which my user sees --- starts with:

mysqldump: [Warning] Using a password on the command line interface can be insecure.

I am aware of why that is a risk. It would be dishonest of me to censor that. Although I'm beginning to think that external file is a hassle and has holes, so should I bother to change code to it? But if Workbench chooses to do it this way shouldn't I make the same effort? And if my kind of users see that warning they'll have kittens, so I do think I need to do the external file after all as best I can...

VRonin

@JNBarchan said in Question about QProcess and deleting a file:

OK, I guess I'll have to reveal what this subprocess is!
mysqldump

That makes everything much more simple. The subprocess has no vulnerability, you can store your credential in encrypted format so, even if the file remains around, it will be just gibberish to any attacher.

https://dev.mysql.com/doc/refman/5.7/en/mysql-config-editor.html

JonB

@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.

mchinand

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.

JonB

@mchinand
Ooohhh, that's interesting. Where do you get the MYSQL_PWD environment variable documentation from, please?

mchinand

@JNBarchan said in Question about QProcess and deleting a file:

@mchinand
Ooohhh, that's interesting. Where do you get the MYSQL_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)

JonB

@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!

mrjj

@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.

JonB

@mrjj

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 via ps. In that sense, the command-line argument is actually safer, because mysqldump 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.

mrjj

@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.

JonB

@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.

mrjj

@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 :)

mchinand

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 this write or not. No temporary file containing the password, no password on the command-line, no password in environment variables.

JonB

@mchinand
Ah, now that is interesting indeed. I shall give it a try and report back....