Ulf Lamping wrote:
Hmmm, that sounds *really* strange to me.
We open the capture file with the permission 0600. This means no one
else than the owner can read/write it.
Has someone the possibility to rename a file that belongs only to me???
In general, they do. If they have write permission on the directory in
which the file resides, they can rename the file.
/tmp is publicly writable.
If yes, I would consider *this* to be a security hole in general!
However, for that very reason, the Berkeley UNIX developers made the
"sticky" bit (which, in very old UNIXes, meant "if this file is a
shareable executable image, keep the copy of it in swap space around
even if no process is currently running that code, so that a subsequent
exec of the code can use the copy rather than having to read the code
from the file" - with demand-paged executables, that's not used) mean,
for a directory, "don't allow files to be removed or renamed except by
the owner of the file, the owner of the directory, or the super-user",
and set that bit on "/tmp", to close that hole.
The same is true of "/var/tmp" (or, at the time the Berkeley folks
invented "sticky directories", "/usr/tmp") - at least in Mac OS X
10.3.8, "/var/tmp" is also sticky.
So that *shouldn't* be an issue.
Perhaps the OpenBSD changes were made as a "this is the right way to
share the file" change, so as to eliminate even possibilities that they
couldn't think of but that they might have missed, rather than being
made because they knew of an exploitable security hole.
If no one else than me (well, and root) is able to rename this file,
there's no security problem I see. It's the same as opening any other
capture file that belongs to me.
Yes, it *should* be safe - I'm just worried about security holes I
*can't* see.
Why do you think passing the fd isn't possible, as it was in the code
before, just the other way round?
Because, although, at least in UN*X, you can always pass a file
descriptor from a parent process to a child process at the time the
child process is created (in fact, you have to make a special effort
*not* to pass it, either by closing it in the child after the fork or by
setting the "close on execute" flag on the descriptor if the child will
be doing an exec)...
In the former implementation the parent opened the fd and handed it over
to the child. Now the child opens the file and could hand this fd to
it's parent.
...passing a file descriptor in any *other* circumstance requires a
special mechanism to attach a file descriptor to an inter-process
message. You can pass the file descriptor *number*, but, in the process
that receives the number, that number won't refer to the same descriptor
- file descriptor numbers are per-process, not global, in UN*X, and are
probably per-process in Win32 as well (as are, presumably, HANDLE
values, although I think file descriptors in Win32 refer to data
structures in the C runtime library, probably as an index into a table
of those structures; if so, the data structure in question probably
includes a HANDLE for the file).
