A gem for handling temporary file(s)?
in [Ruby]
|
Prev: Increase significant digits in Float
Next: Training
From: Caleb Clausen on 3 Mar 2010 17:41 On 3/3/10, Robert Klemme <shortcutter(a)googlemail.com> wrote: > On 03/03/2010 08:35 PM, Caleb Clausen wrote: >> I'm not expert enough to be certain about this, but by doing this >> you'll be creating a tempfile race condition security hole in your >> program. I think the same goes for Robert's suggestion as well. > > Do you mean there is a robustness issue or a security issue? I don't > see a security issue here. Robustness would only be at risk if the file > name generation algorithm is bad. What else am I missing? It's a security issue. See: http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html and scroll down to "7.10.1.2. Temporary Files" As I implied above, I may not know what I'm talking about here, but I'm fairly sure. Also, I didn't contemplate the snippet you contributed closely; perhaps it avoids the race condition in some clever way that I'm unaware of. >> There >> may be a way to do it securely... but it's probably tricky. One >> advantage of Tempfile (and similar facilities in other languages) is >> that it avoids this subtle and nassty security hole. But you have to >> use it the way it wants to be used, otherwise you defeat the security. >> This is why you're better off rewriting this external command in ruby, >> if that's possible. Or rewriting your ruby script to make it an >> integral part of the external program. >> >> None of this may actually matter in your case... but you're the only >> one with enough information to make that judgment. > > Albert still did not disclose what the external program should do with > the temporary file. We do not even know whether it is an option to > rewrite the external program. Yes, indeed. Which is why I said "if that's possible".
From: Caleb Clausen on 3 Mar 2010 18:16 On 3/3/10, Caleb Clausen <vikkous(a)gmail.com> wrote: > There > may be a way to do it securely... but it's probably tricky. I _think_ that if you create a temporary file with Tempfile, and then DON'T CLOSE IT, you can safely pass the tempfile's name to an external command. (I'm assuming that the tempfile is an output from the external command.... if it's an input, none of my security anxieties apply. I think.) Only close the tempfile once the external command has finished (and you've read out of it whatever information you need). This will fail if the external command balks at writing to an already existing file. Alternatively, you could put your temp file in $HOME/tmp rather than the system-wide /tmp, which is another way to sidestep the race. I'm pretty sure. If you go this way, Tempfile is useless to you, tho.
From: Tanaka Akira on 3 Mar 2010 18:50 2010/3/4 Caleb Clausen <vikkous(a)gmail.com>: > Alternatively, you could put your temp file in $HOME/tmp rather than > the system-wide /tmp, which is another way to sidestep the race. I'm > pretty sure. If you go this way, Tempfile is useless to you, tho. Another way is Dir.mktmpdir in tmpdir. require 'tmpdir' Dir.mktmpdir {|d| tmppath = File.join(d, "foo") ... use tmppath ... } -- Tanaka Akira
From: Albert Schlef on 4 Mar 2010 05:19 Robert Klemme wrote: > On 03/03/2010 08:35 PM, Caleb Clausen wrote: >> one with enough information to make that judgment. >> > Albert still did not disclose what the external program should do with > the temporary file [...] Thank you all, this task is behind me already. If it interests you, then the external command I'm using is 'dot' (from the graphviz package). The command I'm using is something like this: dot "%s" -Tgif -o "%s" -Tsvg -o "%s" (I need three temporary files, in this example. 'dot' reads the first file and writes images to the next two files.) Smart guys would say that instead, on POSIX systems, I could write the command as... dot /dev/fd/10 -Tgif -o /dev/fd/11" -Tsvg -o /dev/fd/12 ...but then I'd need to read simultaneously from fd/11 and fd/12 because I'm not sure which is written first. But I need my program to work on Windows too and I'm not sure it supports this "sophistication". Caleb Clausen wrote: > I'm not expert enough to be certain about this, but by doing this > you'll be creating a tempfile race condition [...] I don't care much about robustness because the command is run from an interactive application by a single user and I'm using the files immediately. There isn't much a chance for a race condition. Caleb Clausen wrote: > I _think_ that if you create a temporary file with Tempfile, and then > DON'T CLOSE IT, you can safely pass the tempfile's name to an external > command. For some reason, the files aren't always deleted (well, it seems they're never deleted). I don't know why. At first I suspected 'dot' re-creates the files, but when I do "ls -i" I see that the inodes haven't changed. But I can live with this bug. Maybe I could add some code to the "destructor" of my class to explicitly delete these files. Does Ruby support "destructors"? -- Posted via http://www.ruby-forum.com/.
From: Robert Klemme on 4 Mar 2010 10:24
2010/3/4 Albert Schlef <albertschlef(a)gmail.com>: > Robert Klemme wrote: >> On 03/03/2010 08:35 PM, Caleb Clausen wrote: >>> one with enough information to make that judgment. >>> >> Albert still did not disclose what the external program should do with >> the temporary file [...] > > Thank you all, this task is behind me already. Considering your last comment about files not being deleted I'd say it's not done yet. :-) > If it interests you, then the external command I'm using is 'dot' (from > the graphviz package). > > The command I'm using is something like this: > > dot "%s" -Tgif -o "%s" -Tsvg -o "%s" > > (I need three temporary files, in this example. 'dot' reads the first > file and writes images to the next two files.) > > Smart guys would say that instead, on POSIX systems, I could write the > command as... > > dot /dev/fd/10 -Tgif -o /dev/fd/11" -Tsvg -o /dev/fd/12 > > ...but then I'd need to read simultaneously from fd/11 and fd/12 because > I'm not sure which is written first. But I need my program to work on > Windows too and I'm not sure it supports this "sophistication". Yeah, probably not a good idea to go into that direction. Btw, do you need to read those files while they are written or is it sufficient to wait for process termination (e.e. use system) before you access them? > Caleb Clausen wrote: >> I'm not expert enough to be certain about this, but by doing this >> you'll be creating a tempfile race condition [...] > > I don't care much about robustness because the command is run from an > interactive application by a single user and I'm using the files > immediately. There isn't much a chance for a race condition. > > Caleb Clausen wrote: >> I _think_ that if you create a temporary file with Tempfile, and then >> DON'T CLOSE IT, you can safely pass the tempfile's name to an external >> command. > > For some reason, the files aren't always deleted (well, it seems they're > never deleted). I don't know why. At first I suspected 'dot' re-creates > the files, but when I do "ls -i" I see that the inodes haven't changed. > But I can live with this bug. Maybe I could add some code to the > "destructor" of my class to explicitly delete these files. Does Ruby > support "destructors"? We have begin ... ensure ... end The usual way to do this is to write a method. See http://blog.rubybestpractices.com/posts/rklemme/002_Writing_Block_Methods.html Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ |