When we create a process yourself with CreateProcess, we get a
handle to the process in the PROCESS_INFO output structure. But
instead of using that handle, we were manually looking up a _new_
handle based on the process ID, which is a poor idea, since the
process ID might refer to a new process later on, but the handle
can't.
This lets us avoid sending SIGTERM to something that has already
died, since we realize it has already died, and is a fix for the
unix version of #8746.
When running with User set, we frequently try to look up our
information in the user database (e.g., /etc/passwd). The seccomp2
sandbox setup doesn't let us open /etc/passwd, and probably
shouldn't.
To fix this, we have a pair of wrappers for getpwnam and getpwuid.
When a real call to getpwnam or getpwuid fails, they fall back to a
cached value, if the uid/gid matches.
(Granting access to /etc/passwd isn't possible with the way we
handle opening files through the sandbox. It's not desirable either.)
On OpenBSD 5.4, time_t is a 32-bit integer. These instances contain
implicit treatment of long and time_t as comparable types, so explicitly
cast to time_t.
Most of these are simple. The only nontrivial part is that our
pattern for using ENUM_BF was confusing doxygen by making declarations
that didn't look like declarations.
This flag prevents the creation of a console window popup on Windows. We
need it for pluggable transport executables--otherwise you get blank
console windows when you launch the 3.x browser bundle with transports
enabled.
http://msdn.microsoft.com/en-us/library/ms684863.aspx#CREATE_NO_WINDOW
The browser bundles that used Vidalia used to set this flag when
launching tor itself; it was apparently inherited by the pluggable
transports launched by tor. In the 3.x bundles, tor is launched by some
JavaScript code, which doesn't have the ability to set CREATE_NO_WINDOW.
tor itself is now being compiled with the -mwindows option, so that it
is a GUI application, not a console application, and doesn't show a
console window in any case. This workaround doesn't work for pluggable
transports, because they need to be able to write control messages to
stdout.
https://trac.torproject.org/projects/tor/ticket/9444#comment:30
On platforms with the backtrace/backtrace_symbols_fd interface, Tor
can now dump stack traces on assertion failure. By default, I log
them to DataDir/stack_dump and to stderr.
Conflicts:
src/or/or.h
src/or/relay.c
Conflicts were simple to resolve. More fixes were needed for
compilation, including: reinstating the tv_to_msec function, and renaming
*_conn_cells to *_chan_cells.
This is probably not an exploitable bug, since you would need to have
errno be a large negative value in the unix pluggable-transport launcher
case. Still, best avoided.
Fixes bug 9928; bugfix on 0.2.3.18-rc.
Better tests for upper bounds, and for failing cases.
Also, change the function's interface to take a buffer length rather
than a maximum length, and then NUL-terminate: functions that don't
NUL-terminate are trouble waiting to happen.
The only thing that used format_helper_exit_status on win32 was the
unit tests. This caused an error when we tried to leave a static
format_helper_exit_status lying around in a production object file.
The easiest solution is to admit that this way of dealing with process
exit status is Unix-only.
We previously used FILENAME_PRIVATE identifiers mostly for
identifiers exposed only to the unit tests... but also for
identifiers exposed to the benchmarker, and sometimes for
identifiers exposed to a similar module, and occasionally for no
really good reason at all.
Now, we use FILENAME_PRIVATE identifiers for identifiers shared by
Tor and the unit tests. They should be defined static when we
aren't building the unit test, and globally visible otherwise. (The
STATIC macro will keep us honest here.)
For identifiers used only by the unit tests and never by Tor at all,
on the other hand, we wrap them in #ifdef TOR_UNIT_TESTS.
This is not the motivating use case for the split test/non-test
build system; it's just a test example to see how it works, and to
take a chance to clean up the code a little.
Without this patch, there's no way to know what went wrong when we
fail to parse a torrc line entirely (that is, we can't turn it into
a K,V pair.) This patch introduces a new function that yields an
error message on failure, so we can at least tell the user what to
look for in their nonfunctional torrc.
(Actually, it's the same function as before with a new name:
parse_config_line_from_str is now a wrapper macro that the unit
tests use.)
Fixes bug 7950; fix on 0.2.0.16-alpha (58de695f90) which first
introduced the possibility of a torrc value not parsing correctly.
- Document the key=value format.
- Constify equal_sign_pos.
- Pass some strings that are about to be logged to escape().
- Update documentation and fix some bugs in tor_escape_str_for_socks_arg().
- Use string_is_key_value() in parse_bridge_line().
- Parenthesize a forgotten #define
- Add some more comments.
- Add some more unit test cases.
We need a weak RNG in a couple of places where the strong RNG is
both needless and too slow. We had been using the weak RNG from our
platform's libc implementation, but that was problematic (because
many platforms have exceptionally horrible weak RNGs -- like, ones
that only return values between 0 and SHORT_MAX) and because we were
using it in a way that was wrong for LCG-based weak RNGs. (We were
counting on the low bits of the LCG output to be as random as the
high ones, which isn't true.)
This patch adds a separate type for a weak RNG, adds an LCG
implementation for it, and uses that exclusively where we had been
using the platform weak RNG.
This is meant to avoid conflict with the built-in log() function in
math.h. It resolves ticket 7599. First reported by dhill.
This was generated with the following perl script:
#!/usr/bin/perl -w -i -p
s/\blog\(LOG_(ERR|WARN|NOTICE|INFO|DEBUG)\s*,\s*/log_\L$1\(/g;
s/\blog\(/tor_log\(/g;
Apparently some compilers like to eliminate memset() operations on
data that's about to go out-of-scope. I've gone with the safest
possible replacement, which might be a bit slow. I don't think this
is critical path in any way that will affect performance, but if it
is, we can work on that in 0.2.4.
Fixes bug 7352.
add read_file_to_str_until_eof which is used by read_file_to_str
if the file happens to be a FIFO.
change file_status() to return FN_FILE if st_mode matches S_IFIFO
(on not-windows) so that init_key_from_file() will read from a FIFO.
We already had code on windows to fix our file sizes when we're
reading a file in text mode and its size doesn't match the size from
fstat. But that code was only enabled when _WIN32 was defined, and
Cygwin defines __CYGWIN__ instead.
Fixes bug 6844; bugfix on 0.1.2.7-alpha.
This would be undefined behavior if it happened. (It can't actually
happen as we're using round_to_power_of_2, since we would have to
be trying to allocate exabytes of data.)
While we're at it, fix the behavior of round_to_power_of_2(0),
and document the function better.
Fix for bug 6831.
Add handle_fw_helper_output(), a function responsible for parsing the
output of tor-fw-helper. Refactor tor_check_port_forwarding() and
run_scheduled_events() accordingly too.
We now issue warnings when we get control output from tor-fw-helper,
and we log the verbose output of tor-fw-helper in LOG_INFO.
Conflicts:
src/common/util.c
get_lines_from_handle() is a multiplatform function which drains lines
from a stream and stuffs it into a smartlist. It's useful for
line-based protocols, like the one managed proxy and the tor-fw-helper
protocols.
This should make our preferred solution to #6538 easier to
implement, avoid a bunch of potential nastiness with excessive
int-vs-double math, and generally make the code there a little less
scary.
"But wait!" you say. "Is it really safe to do this? Won't the
results come out differently?"
Yes, but not much. We now round every weighted bandwidth to the
nearest byte before computing on it. This will make every node that
had a fractional part of its weighted bandwidth before either
slighty more likely or slightly less likely. Further, the rand_bw
value was only ever set with integer precision, so it can't
accurately sample routers with tiny fractional bandwidth values
anyway. Finally, doing repeated double-vs-uint64 comparisons is
just plain sad; it will involve an implicit cast to double, which is
never a fun thing.
With glibc 2.15 and clang 3.0, I get warnings from where we use the
strcpsn implementation in the header as strcspn(string, "="). This
is apparently because clang sees that part of the strcspn macro
expands to "="[2], and doesn't realize that that part of the macro
is only evaluated when "="[1] != 0.
We can treat this case as an EAGAIN (probably because of an
unexpected internal NUL) rather than a crash-worthy problem.
Fixes bug 6225, again. Bug not in any released version of Tor.
Because the string output was no longer equal in length to
HEX_ERRNO_SIZE, the write() call would add some extra spaces and
maybe a NUL, and the NUL would trigger an assert in
get_string_from_pipe.
Fixes bug 6225; bug not in any released version of Tor.
The function is not guaranteed to NUL-terminate its output. It
*is*, however, guaranteed not to generate more than two bytes per
multibyte character (plus terminating nul), so the general approach
I'm taking is to try to allocate enough space, AND to manually add a
NUL at the end of each buffer just in case I screwed up the "enough
space" thing.
Fixes bug 5909.
These include:
- Having a weird in_addr that can't be initialized with {0}
- Needing INVALID_HANDLE_VALUE instead of -1 for file handles.
- Having a weird dependent definition for struct stat.
- pid is signed, not unsigned.
Also, try to resolve some doxygen issues. First, define a magic
"This is doxygen!" macro so that we take the correct branch in
various #if/#else/#endifs in order to get the right documentation.
Second, add in a few grouping @{ and @} entries in order to get some
variables and fields to get grouped together.
* It seems parse_http_time wasn't parsing correctly any date with commas (RFCs
1123 and 850). Fix that.
* It seems parse_http_time was reporting the wrong month (they start at 0, not
1). Fix that.
* Add some tests for parse_http_time, covering all three formats.
The underlying strtoX functions handle overflow by saturating and
setting errno to ERANGE. If the min/max arguments to the
tor_parse_* functions are equal to the minimum/maximum of the
underlying type, then with the old approach, we wouldn't treat a
too-large value as genuinely broken.
Found this while looking at bug 5786; bugfix on 19da1f36 (in Tor
0.0.9), which introduced these functions.
They boil down to:
- MS_WINDOWS is dead and replaced with _WIN32, but we let a few
instances creep in when we merged Esteban's tests.
- Capitalizing windows header names confuses mingw.
- #ifdef 0 ain't C.
- One unit test wasn't compiled on windows, but was being listed
anyway.
- One unit test was checking for the wrong value.
Gisle Vanem found and fixed the latter 3 issues.
One of our unit tests checks that they behave correctly (giving an
error) when the base is negative. But there isn't a guarantee that
strtol and friends actually handle negative bases correctly.
Found by Coverity Scan; fix for CID 504.
