| Ticket UUID: | 402924 | |||
| Title: | Fix for race condition in unix/tclUnixPipe.c | |||
| Type: | Patch | Version: | None | |
| Submitter: | rmax | Created on: | 2000-12-19 14:52:45 | |
| Subsystem: | 27. Channel Types | Assigned To: | hobbs | |
| Priority: | 5 Medium | Severity: | ||
| Status: | Closed | Last Modified: | 2001-03-30 03:59:56 | |
| Resolution: | Fixed | Closed By: | hobbs | |
| Closed on: | 2001-03-29 20:59:56 | |||
| User Comments: |
hobbs added on 2001-03-30 03:59:56:
Logged In: YES
user_id=72656
And on Solaris, the USAGE notes say:
...
The tmpfile(3S) function is preferred over this
function.
...
Each seems to have problems, so I'll just do the O_EXCL for
now. If someone wants to make a larger patch the goes with
the conflicting advice of OSes, that should be separate.
I've patched as per the original suggestion for 8.4a2/8.3.3.
rmax added on 2001-03-29 13:13:54: Logged In: YES
user_id=124643
It is only a very tight race condition, but it exists. If
someone creates a symlink in the time between tmpnam() and
open() that has the same name as the temporary file you are
about to open, the target file of this symlink will be
deleted, if open is called with O_TRUNC.
Adding O_NOFOLLOW instead of replacing O_TRUNC with O_EXCL
may also help, but seems to be less portable.
BTW, the manpage of tmpnam says:
BUGS
Never use this function. Use mkstemp(3) instead.
hobbs added on 2001-03-29 08:39:14: Logged In: YES user_id=72656 No need to create a bug first is necessary, but a bit of explanation is always nice. :^) In the case of this patch, it does change the meaning of the open call from truncating any existing file to throwing an error if the file exists. Of course, this shouldn't happen with tmpnam and all, but then I wonder how it is a security leak? I'm inclined to believe the security guys, I just wanted to know more about how a problem could occur. hobbs added on 2001-03-29 08:38:49: Logged In: YES user_id=72656 No need to create a bug first is necessary, but a bit of explanation is always nice. :^) In the case of this patch, it does change the meaning of the open call from truncating any existing file to throwing an error if the file exists. Of course, this shouldn't happen with tmpnam and all, but then I wonder how it is a security leak? I'm inclined to believe the security guys, I just wanted to know more about how a problem could occur. rmax added on 2000-12-21 17:18:52: Am I supposed to create a bug entry before I submit a patch? This patch fixes a security leak that makes Tcl vulnerable to symlink attacks when it creates temporary files. I was pointed to this by our security experts. andreas_kupries added on 2000-12-21 16:34:02: To which bug does this patch belong to ? rmax added on 2000-12-19 21:54:36: oops, the path in the summary should read unix/tclUnixPipe.c | |||
Attachments:
- None [download] added by rmax on 2000-12-19 21:52:45. [details]