A gem for handling temporary file(s)?
in [Ruby]
|
Prev: Increase significant digits in Float
Next: Training
From: Caleb Clausen on 4 Mar 2010 14:36 On 3/4/10, Albert Schlef <albertschlef(a)gmail.com> wrote: > 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. It's not (just) a robustness issue, but a security issue. Even if there's not much chance for a race condition, that can create a very large security hole. I'd suggest you should take a look at the link I posted in reply to Robert above. I just want to make sure you're aware.
From: Daniel Berger on 4 Mar 2010 15:24 On Mar 3, 2:13 pm, Caleb Clausen <vikk...(a)gmail.com> wrote: > On 3/3/10, Daniel Berger <djber...(a)gmail.com> wrote: > > > Bah. Use file-temp. > > > gem install file-temp > > I can't get file-temp to install at the moment, (for reasons unrelated > to file-temp, apparently). Does file-temp allow one to create > temporary _directories_? That's a feature I've often missed in the > past. No, but there's Dir.mktmpdir. Regards, Dan
From: Caleb Clausen on 4 Mar 2010 21:13 On 3/4/10, Daniel Berger <djberg96(a)gmail.com> wrote: > On Mar 3, 2:13 pm, Caleb Clausen <vikk...(a)gmail.com> wrote: >> to file-temp, apparently). Does file-temp allow one to create >> temporary _directories_? That's a feature I've often missed in the >> past. > > No, but there's Dir.mktmpdir. Thanks to you and to Tanaka Akira for pointing this out, since I was not aware of it. I'll definitely remember it next time I need that.
From: Albert Schlef on 4 Mar 2010 23:22 Robert Klemme wrote: > 2010/3/4 Albert Schlef <albertschlef(a)gmail.com>: >> dot ... -Tgif -o ... -Tsvg -o ... [...] > 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? (I read the files after termination (I'm using system()).) >> 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 Thanks. I know this scheme (and the article), but for some reason it didn't come up to my mind to use it. You just gave me a nice idea. I need to read more Ruby code to train myself. The problem is that I love to program so I prefer writing to reading :-( Caleb Clausen wrote: > It's not (just) a robustness issue, but a security issue. Even if > there's not much chance for a race condition, that can create a very > large security hole. I'd suggest you should take a look at the link I > posted in reply to Robert above. I just want to make sure you're > aware. You mean a privacy issue. Yes, I fixed that. Thanks. -- Posted via http://www.ruby-forum.com/.
From: Robert Klemme on 5 Mar 2010 07:20
2010/3/3 Caleb Clausen <vikkous(a)gmail.com>: > 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. Thanks for the link. If I understand all this right this cannot be fixed as long as a) there are two processes involved or b) the second process (dot) cannot be made inherit the file descriptor. An alternative approach would avoid a shared directory like /tmp and write the output in $HOME/.../somewhere - which might be slower because /tmp is often mounted in RAM. Maybe it helps to create a directory in /tmp which is owned by and only accessible to $USER; then create the tempfiles in that directory. >>> 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". Yep. I mainly included the remark to poke Albert so he would eventually give the information. ;-) Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ |