Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#13904 closed defect (fixed)

Tests fail on Gentoo

Reported by: toralf Owned by: atagar
Priority: Medium Milestone:
Component: Core Tor/Stem Version:
Severity: Keywords: testing
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

For some reason I just fired uo here at a 64 bit hardened Gentoo Linux the command :

tor-relay /usr/local/portage/net-libs/stem # time ebuild stem-1.2.2_p20141205.ebuild test
Forcing test.
 * stem-1.2.2_p20141205.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                  [ ok ]

which hangs here now since a while :

----------------------------------------------------------------------
Ran 19 tests in 0.062s

FAILED (failures=1, errors=2)
  util.conf...                                         success (0.00s)
  util.proc...                                         success (0.02s)
  util.str_tools...                                    success (0.00s)
  util.system...                                       success (0.03s)
  util.tor_tools...                                    success (0.00s)
  descriptor.export...                                 success (0.01s)
  descriptor.reader...                                Exception in thread Descriptor Reader:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141205/work/stem-1.2.2_p20141205/stem/descriptor/reader.py", line 429, in _read_descriptor_files
    self._handle_walker(walker, new_processed_files)
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141205/work/stem-1.2.2_p20141205/stem/descriptor/reader.py", line 457, in _handle_walker
    self._handle_file(os.path.join(root, filename), new_processed_files)
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141205/work/stem-1.2.2_p20141205/stem/descriptor/reader.py", line 493, in _handle_file
    self._handle_descriptor_file(target, target_type)
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141205/work/stem-1.2.2_p20141205/stem/descriptor/reader.py", line 505, in _handle_descriptor_file
    for desc in stem.descriptor.parse_file(target_file, validate = self._validate, document_handler = self._document_handler, **self._kwargs):
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141205/work/stem-1.2.2_p20141205/stem/descriptor/__init__.py", line 212, in parse_file
    for desc in file_parser(descriptor_file):
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141205/work/stem-1.2.2_p20141205/stem/descriptor/microdescriptor.py", line 149, in _parse_file
    yield Microdescriptor(descriptor_text, validate, annotations, **kwargs)
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141205/work/stem-1.2.2_p20141205/stem/descriptor/microdescriptor.py", line 196, in __init__
    self._parse(entries, validate)
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141205/work/stem-1.2.2_p20141205/stem/descriptor/microdescriptor.py", line 269, in _parse
    stem.descriptor.router_status_entry._parse_a_line(self, entry, validate)
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141205/work/stem-1.2.2_p20141205/stem/descriptor/router_status_entry.py", line 554, in _parse_a_line
    raise ValueError("%s 'a' line must start with an IPv6 address: a %s" % (desc._name(), value))
AttributeError: 'Microdescriptor' object has no attribute '_name'

FWIW:
COMMIT_ID="72ef5421eb1611ad9dec9e210dd20b4d2e977b03"

hope this helps ...

Child Tickets

Attachments (2)

net-libs:stem-1.2.2_p20141206:20141206-105919.log.gz (11.6 KB) - added by toralf 3 years ago.
test output
net-libs:stem-1.2.2_p20141208:20141207-110956.log.gz (8.1 KB) - added by toralf 3 years ago.
test results for 4e2473d98c88399d1fd00e4c92ae215c092188b7

Download all attachments as: .zip

Change History (35)

comment:1 Changed 3 years ago by atagar

  • Resolution set to fixed
  • Status changed from new to closed

Interesting! Unit tests should be deterministic, but guess there's a timing issue here.

Thanks! That was definitely a bug. The Reader was supposed to run into malformed descriptor content and did, but rather than raise a ValueError this bug caused it to raise a AttributeError. Fixed...

https://gitweb.torproject.org/stem.git/commit/?id=90bb28f44929bcb33b321eb51a27bb247c4ae6ab

Changed 3 years ago by toralf

test output

comment:2 Changed 3 years ago by toralf

so, tests do now finished, however at a hardened Gentoo Linux few tests do fail.

comment:3 follow-up: Changed 3 years ago by atagar

  • Resolution fixed deleted
  • Status changed from closed to reopened

Interesting! This is indicating that a recent-ish change to use the socket module to validate ip addresses is failing on your system for some reason. What happens if you open a python interpretor and do the following?

>>> import socket

>>> socket.inet_pton(socket.AF_INET6, '1::1')
'\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01'

I expect in your case it'll raise a socket.error of some kind. Little curious about that (... these failures seem to indicate your system doesn't know what an IPv6 address looks like).

Pity. Thought we could rely on the python builtins for this but maybe not.

comment:4 follow-up: Changed 3 years ago by atagar

Just pushed a change that should fix the tests. Please let me know if they pass or not, and thanks for the catch!

https://gitweb.torproject.org/stem.git/commit/?id=91f6c3bb2a5a4f4bb9a822f1280a4c250aeacdcd

comment:5 in reply to: ↑ 3 Changed 3 years ago by toralf

Replying to atagar:

Interesting! This is indicating that a recent-ish change to use the socket module to validate ip addresses is failing on your system for some reason. What happens if you open a python interpretor and do the following?

>>> import socket

>>> socket.inet_pton(socket.AF_INET6, '1::1')
'\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01'
tfoerste@tor-relay ~ $ python2
Python 2.7.7 (default, Oct 25 2014, 11:03:42)
[GCC 4.8.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.inet_pton(socket.AF_INET6, '1::1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.error: can't use AF_INET6, IPv6 is disabled
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>>

comment:6 Changed 3 years ago by atagar

Gotcha. And do the tests now pass?

comment:7 in reply to: ↑ 4 Changed 3 years ago by toralf

Replying to atagar:

Just pushed a change that should fix the tests. Please let me know if they pass or not, and thanks for the catch!

https://gitweb.torproject.org/stem.git/commit/?id=91f6c3bb2a5a4f4bb9a822f1280a4c250aeacdcd

yes, latest git gives now :

Shutting down tor... done

Static error checking requires pyflakes version 0.7.3 or later. Please install it from ...
  http://pypi.python.org/pypi/pyflakes

Style checks require pep8 version 1.4.2 or later. Please install it from...
  http://pypi.python.org/pypi/pep8

TESTING FAILED (202 seconds)
  [RUN_PTRACE] test_get_connections (test.integ.util.connection.TestConnection) ... ERROR
  [RUN_PTRACE] test_connections (test.integ.util.proc.TestProc) ... ERROR
  [RUN_PTRACE] test_pid_by_port (test.integ.util.system.TestSystem) ... FAIL
  [RUN_PTRACE] test_pid_by_port_lsof (test.integ.util.system.TestSystem) ... ERROR
  [RUN_PTRACE] test_pid_by_port_netstat (test.integ.util.system.TestSystem) ... ERROR
 * ERROR: net-libs/stem-1.2.2_p20141207::toralf failed (test phase):

comment:8 Changed 3 years ago by atagar

  • Resolution set to fixed
  • Status changed from reopened to closed

Great, thanks!

  [RUN_PTRACE] test_get_connections (test.integ.util.connection.TestConnection) ... ERROR
  [RUN_PTRACE] test_connections (test.integ.util.proc.TestProc) ... ERROR
  [RUN_PTRACE] test_pid_by_port (test.integ.util.system.TestSystem) ... FAIL
  [RUN_PTRACE] test_pid_by_port_lsof (test.integ.util.system.TestSystem) ... ERROR
  [RUN_PTRACE] test_pid_by_port_netstat (test.integ.util.system.TestSystem) ... ERROR
 * ERROR: net-libs/stem-1.2.2_p20141207::toralf failed (test phase):

Interesting, but in looking at the earlier output I suppose this shouldn't be surprising...

======================================================================
ERROR: test_get_connections
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141206/work/stem-1.2.2_p20141206/test/integ/util/connection.py", line 27, in test_get_connections
    connections = get_connections(resolver, process_pid = tor_pid)
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141206/work/stem-1.2.2_p20141206/stem/util/connection.py", line 178, in get_connections
    return [Connection(*conn) for conn in stem.util.proc.connections(process_pid)]
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141206/work/stem-1.2.2_p20141206/stem/util/proc.py", line 404, in connections
    raise exc
IOError: unable to read '/proc/net/tcp': [Errno 13] Permission denied: '/proc/net/tcp'

Other errors are due to netstat and lsof being broken, which is understandable given the hardening. If you have an 'is this system hardened' check then we can add a clause to skip the tests but otherwise it sounds like there's no further issues. Feel free to reopen if there's anything else!

comment:9 Changed 3 years ago by atagar

Hi toralf, this ticket got me thinking about Gentoo and I was delighted to realize Anthony's packaged it for the distro. Added Gentoo to our download page...

https://stem.torproject.org/download.html

comment:10 Changed 3 years ago by atagar

I spotted the Gentoo ticket I suspect you might be looking into...

https://bugs.gentoo.org/show_bug.cgi?id=527072

Interesting. Made a couple more fixes for it...

https://gitweb.torproject.org/stem.git/commit/?id=2ee4e95ab0f2640674c1074ce26e2f09ce9bdf26
https://gitweb.torproject.org/stem.git/commit/?id=4e2473d98c88399d1fd00e4c92ae215c092188b7

However, the PTRACE target failures you mention remain. Probably the best way of addressing those is to simply skip those test on Gentoo. This requires an is_gentoo() method like...

https://gitweb.torproject.org/stem.git/tree/stem/util/system.py#n124

What does platform.system() provide for you? If it's not something distinct then is there something else you'd suggest?

comment:11 Changed 3 years ago by atagar

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Summary changed from unit tests do hang to Tests fail on Gentoo

comment:12 Changed 3 years ago by atagar

  • Keywords testing added

comment:13 Changed 3 years ago by toralf

Hi,

thx for adding Gentoo to the wiki.
Gentoo might be detected in this way :

$ cat /etc/gentoo-release
Gentoo Base System release 2.2

In this case the sub-architecture is specified via :

$ ls -l /etc/portage/make.profile
lrwxrwxrwx 1 root root 47 Oct 24 22:32 /etc/portage/make.profile -> ../../usr/portage/profiles/hardened/linux/amd64

another example would be:
$ ls -l /etc/portage/make.profile
lrwxrwxrwx 1 root root 61 Jan 19 2013 /etc/portage/make.profile -> ../../usr/portage/profiles/default/linux/x86/13.0/desktop/kde

test results of latest git will follow soon

comment:14 Changed 3 years ago by atagar

$ cat /etc/gentoo-release

Perfect! Thanks.

test results of latest git will follow soon

I wasn't expecting the PTRACE results to change (the fixes I mentioned above were for the Gentoo ticket, which was about test failures due to lacking network access). However, I just pushed some changes for the PTRACE tests.

util.proc... failed (0.01s)
util.system... failed (0.38s)

These should now pass. We now check for proc read permissions and skip certain tests on Gentoo.

util.connection... failed (0.01s)

This one, however, is a bit more interesting. You should no longer get that proc error, but I'd like to know if all resolvers are broken on Gentoo or just that one. I changed the test so it'll run each resolver separately.

Would you mind re-running the tests?

Thanks! -Damian

comment:15 Changed 3 years ago by toralf

HHm, it hangs here now :

Setting up a test instance...
  making test directory (/var/tmp/portage/net-libs/stem-1.2.2_p20141210/work/stem-1.2.2_p20141210/test/data)... skipped
  making control socket directory (/var/tmp/portage/net-libs/stem-1.2.2_p20141210/temp/793314d6-6415-4f55-9e41-249e56e26869)... done
  configuring logger (/var/tmp/portage/net-libs/stem-1.2.2_p20141210/work/stem-1.2.2_p20141210/test/data/log)... done
  writing torrc (/var/tmp/portage/net-libs/stem-1.2.2_p20141210/work/stem-1.2.2_p20141210/test/data/torrc)... done
    # configuration for stem integration tests
    DataDirectory /var/tmp/portage/net-libs/stem-1.2.2_p20141210/work/stem-1.2.2_p20141210/test/data
    SocksListenAddress 127.0.0.1:1112
    DownloadExtraInfo 1
    Log notice stdout
    Log notice file /var/tmp/portage/net-libs/stem-1.2.2_p20141210/work/stem-1.2.2_p20141210/test/data/tor_log
    ControlSocket /var/tmp/portage/net-libs/stem-1.2.2_p20141210/temp/793314d6-6415-4f55-9e41-249e56e26869/socket
    CookieAuthentication 1

Starting tor...

  Dec 10 15:42:26.981 [notice] Tor v0.2.5.10 (git-42b42605f8d8eac2) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1j and Zlib 1.2.8.
  Dec 10 15:42:26.981 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
  Dec 10 15:42:26.982 [notice] Read configuration file "/var/tmp/portage/net-libs/stem-1.2.2_p20141210/work/stem-1.2.2_p20141210/test/data/torrc".
  Dec 10 15:42:26.993 [notice] Opening Socks listener on 127.0.0.1:1112
  Dec 10 15:42:26.993 [notice] Opening Control listener on /var/tmp/portage/net-libs/stem-1.2.2_p20141210/temp/793314d6-6415-4f55-9e41-249e56e26869/socket
  Dec 10 15:42:26.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
  Dec 10 15:42:27.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
  Dec 10 15:42:27.000 [notice] Bootstrapped 0%: Starting
  Dec 10 15:42:27.000 [notice] Bootstrapped 5%: Connecting to directory server
  done (0 seconds)

Running tests...

  util.conf...                                         success (0.00s)
  util.connection...                                   success (0.00s)
  util.proc...                                         success (0.01s)
  util.system...                                       success (0.37s)
  descriptor.remote...                                 success (0.00s)
  descriptor.server_descriptor...                      success (0.00s)
  descriptor.extrainfo_descriptor...                   success (0.00s)
  descriptor.microdescriptor...                        success (0.00s)
  descriptor.networkstatus...                          success (0.00s)
  version...                                           success (0.03s)
  response.protocolinfo...                             success (0.07s)
  process...                                           success (0.00s)
  socket.control_socket...                             success (0.30s)
  socket.control_message...                            success (1.21s)
  connection.authentication...                         success (0.14s)
  connection.connect...                                success (0.01s)
  control.base_controller...                           success (5.21s)
  control.controller...                               
                                                                                                                                                                      
 }}}and the log file /var/tmp/portage/net-libs/stem-1.2.2_p20141210/work/stem-1.2.2_p20141210/test/data/tor_log has last lines :

{{{
Dec 10 15:42:40.000 [warn] Hidden service ("test_hidden_service_empty/") with no ports configured; ignoring.
Dec 10 15:42:40.000 [notice] Tor 0.2.5.10 (git-42b42605f8d8eac2) opening log file.
Dec 10 15:42:40.000 [warn] Hidden service ("test_hidden_service_empty/") with no ports configured; ignoring.
Dec 10 15:42:40.000 [notice] New control connection opened.
Dec 10 15:42:40.000 [notice] New control connection opened.
Dec 10 15:42:40.000 [warn] Controller gave us config file that didn't validate: Failed to parse/validate config: While Tor is running, changing DataDirectory ("/var/tmp/portage/net-libs/stem-1.2.2_p20141210/work/stem-1.2.2_p20141210/test/data"->"/var/tmp/portage/net-libs/stem-1.2.2_p20141210/homedir/.tor") is not allowed.
Dec 10 15:42:40.000 [warn] Controller gave us config file that didn't validate: Failed to parse/validate config: Unknown option 'Blahblah'.  Failing.
Dec 10 15:42:40.000 [notice] Tor 0.2.5.10 (git-42b42605f8d8eac2) opening log file.
Dec 10 15:42:40.000 [notice] Tor 0.2.5.10 (git-42b42605f8d8eac2) opening log file.
Dec 10 15:42:40.000 [notice] Tor 0.2.5.10 (git-42b42605f8d8eac2) opening log file.
Dec 10 15:42:40.000 [notice] New control connection opened.
Dec 10 15:42:40.000 [notice] New control connection opened.
Dec 10 15:42:40.000 [notice] New control connection opened.
Dec 10 15:42:40.000 [notice] New control connection opened.
Dec 10 15:42:43.000 [notice] New control connection opened.
Dec 10 15:42:44.000 [notice] New control connection opened.
Dec 10 16:00:46.000 [warn] Received http status code 404 ("Not found") from server '146.0.42.110:25' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".
 }}}

comment:16 Changed 3 years ago by atagar

Well, that's unexpected. Does it hang consistently or was this a one-off? Please give run_tests.py the --verbose flag - maybe that'll shed a hint.

comment:17 Changed 3 years ago by toralf

right, was a one-time thing, now tests passes with

Shutting down tor... done

Static error checking requires pyflakes version 0.7.3 or later. Please install it from ...
  http://pypi.python.org/pypi/pyflakes

Style checks require pep8 version 1.4.2 or later. Please install it from...
  http://pypi.python.org/pypi/pep8

TESTING FAILED (171 seconds)
  [RUN_PTRACE] test_get_connections_by_lsof (test.integ.util.connection.TestConnection) ... ERROR
  [RUN_PTRACE] test_get_connections_by_netstat (test.integ.util.connection.TestConnection) ... ERROR
  [RUN_PTRACE] test_get_connections_by_proc (test.integ.util.connection.TestConnection) ... ERROR
  [RUN_PTRACE] test_get_connections_by_ss (test.integ.util.connection.TestConnection) ... ERROR
  [RUN_PTRACE] test_connections (test.integ.util.proc.TestProc) ... ERROR
 * ERROR: net-libs/stem-1.2.2_p20141210::toralf failed (test phase):
 *   (no error message)

with kernel 3.17.6-hardened

comment:18 Changed 3 years ago by atagar

Well drats. Looks like Gentoo doesn't have any connection resolvers at all then. That's too bad. Made Stem recognize that.

This should fix the test_get_connections_by_* with the exception of test_get_connections_by_proc. That one's indicating that my earlier fix of checking proc permissions isn't working. What are your permissions on /proc/net/tcp and /proc/net/udp? If you run the following what happens?

>>> import os
>>> os.access('/proc/net/tcp', os.R_OK)
True
>>> os.access('/proc/net/udp', os.R_OK)
True

comment:19 Changed 3 years ago by toralf

I do get :

tfoerste@tor-relay ~ $ python2
Python 2.7.7 (default, Oct 25 2014, 11:03:42) 
[GCC 4.8.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.access('/proc/net/tcp', os.R_OK)
True
>>> os.access('/proc/net/udp', os.R_OK)
True
>>> 
tfoerste@tor-relay ~ $ ls -l /proc/net/tcp /proc/net/udp
-r--r--r-- 1 root wheel 0 Dec 10 19:37 /proc/net/tcp
-r--r--r-- 1 root wheel 0 Dec 10 19:37 /proc/net/udp
}}}You might however consider, that it is a hardened Gentoo Linux (kernel is patched with GRsecurity)

comment:20 Changed 3 years ago by atagar

Huh. So the filesystem says we have read permissions but actually reading from it fails with permission denied?

IOError: unable to read '/proc/net/tcp': [Errno 13] Permission denied: '/proc/net/tcp'

Sounds like a GRsecurity bug to me. Oh well, I can add a special 'if Gentoo don't believe the file permissions' check. :(

Presently at work. I'll make it so tomorrow morning. Thanks for checking!

comment:21 Changed 3 years ago by atagar

Fix pushed, the tests should now pass. Can you confirm?

comment:22 Changed 3 years ago by toralf

yeah - good progress, no I just got this :

Shutting down tor... done

Static error checking requires pyflakes version 0.7.3 or later. Please install it from ...
  http://pypi.python.org/pypi/pyflakes

Style checks require pep8 version 1.4.2 or later. Please install it from...
  http://pypi.python.org/pypi/pep8

TESTING FAILED (159 seconds)
  [UNIT TEST] test_system_resolvers (test.unit.util.connection.TestConnection) ... FAIL

which points to this

======================================================================
FAIL: test_system_resolvers
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/mock.py", line 1210, in patched
    return func(*args, **keywargs)
  File "/var/tmp/portage/net-libs/stem-1.2.2_p20141211/work/stem-1.2.2_p20141211/test/unit/util/connection.py", line 121, in test_system_resolvers
    self.assertEqual([Resolver.BSD_SOCKSTAT, Resolver.BSD_PROCSTAT, Resolver.LSOF], stem.util.connection.system_resolvers('FreeBSD'))
AssertionError: Lists differ: ['sockstat (bsd)', 'procstat (... != []

First list contains 3 additional elements.
First extra element 0:
sockstat (bsd)

- ['sockstat (bsd)', 'procstat (bsd)', 'lsof']
+ []

BTW, in the git commit message you shouldn't blame Gentoo. It is the hardened kernel here (grsecurity in this case), which restricts capabilities (I'm convinced, it makes sense to run a hardened kernel, especially if somebody runs a tor relay)

And FWIW a needed a 2nd attempt, the first attempt to run the test failed, b/c the test suite hung at " control.controller..."

comment:23 Changed 3 years ago by atagar

yeah - good progress, no I just got this

Oops! Mistake on my part - fixed. Does it now work?

It is the hardened kernel here (grsecurity in this case), which restricts capabilities (I'm convinced, it makes sense to run a hardened kernel, especially if somebody runs a tor relay)

I'd argue it's a bug with grsecurity. If a process lacks read permissions for a resource then it should reflect that in the filesystem permissions. Grsecurity looks to be lying to processes by saying 'You totally have read access for the proc resources! But... you can't read the proc resources.'

This is my first time running into grsecurity which is why it's conflating with Gentoo for me. On reflection these 'is_gentoo()' checks should really be 'is_grsecurity()' - is there an easy method for detecting it?

comment:24 Changed 3 years ago by toralf

is there an easy method for detecting it?

I fear not, b/c grsecurity prevents most of those methods :-D

But a quick&dirty test could be -for the moment- :
$> uname -a | grep hardened
Linux t44 3.17.6-hardened #7 SMP Fri Dec 12 12:35:58 CET 2014 x86_64 Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz GenuineIntel GNU/Linux

comment:25 Changed 3 years ago by atagar

  • Resolution set to fixed
  • Status changed from reopened to closed

I fear not, b/c grsecurity prevents most of those methods :-D

https://www.youtube.com/watch?v=wRnSnfiUI54

But a quick&dirty test could be -for the moment

Hmmm... this makes me uncomfortable since looking for the string 'hardened' could have false positives, in turn disabling proc resolution erroneously. I'm a little tempted to revert the 'is_gentoo()' checks for proc so when running without grsec Gentoo users will have that feature. But in looking at the other ticket's test output they had the same so guess I'll leave this as-is for now.

Presently connection resolution on Gentoo is disabled and the tests should be passing. Feel free to reopen if we should change anything else.

Thanks for the help!

comment:26 Changed 3 years ago by toralf

Just one question:
Was just the test case modified ? Because with the latest installed stem at that system gives now no resolver at all (worked before):

tfoerste@tor-relay ~ $ sudo python
Python 2.7.7 (default, Oct 25 2014, 11:03:42) 
[GCC 4.8.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> from stem.control import Controller
>>> from stem.util.connection import get_connections, system_resolvers
>>> resolvers = system_resolvers()
>>> print len(resolvers)
0
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>> 

comment:27 Changed 3 years ago by atagar

Was just the test case modified ? Because with the latest installed stem at that system gives now no resolver at all (worked before)

Nope, that's the change I made. The tests indicated that every connection resolver was failing on your platform so I changed system_resolvers() to reflect that none are available due to grsecurity (... actually, the check it's doing is 'none on Gentoo' which is why I asked about a better check).

comment:28 Changed 3 years ago by toralf

And I made a painful braino b/c Gentoo run the tests under the package manager user id and not under root.
But root is needed for a hardened Gentoo, b/c grsecurity restricts a lot of common functionality to just user root).

Oh well, so my delivered results wrt the resolver functionality (starting at #comment 17) are wrong ...

Said this, I run again the tests again the older git status and got this (now the tests run as user root) :

Shutting down tor... done

Static error checking requires pyflakes version 0.7.3 or later. Please install it from ...
  http://pypi.python.org/pypi/pyflakes

Style checks require pep8 version 1.4.2 or later. Please install it from...
  http://pypi.python.org/pypi/pep8

412 TESTS WERE SKIPPED
TESTING PASSED (208 seconds)

>>> Completed testing net-libs/stem-1.2.2_p20141207

tor-relay /usr/local/portage/net-libs/stem # grep ID stem-1.2.2_p20141207.ebuild 
COMMIT_ID="4e2473d98c88399d1fd00e4c92ae215c092188b7"
SRC_URI="https://gitweb.torproject.org/stem.git/snapshot/${COMMIT_ID}.tar.gz -> ${P}.tar.gz"
Last edited 3 years ago by toralf (previous) (diff)

comment:29 Changed 3 years ago by atagar

Ok. How would you care to proceed? As I see it we have three options...

  1. Have system_resolvers() report that no resolvers are available on Gentoo. Advantage is that tests pass, but disadvantage is that it's wrong if you're running as root or without grsec.
  1. Have system_resolvers() treat Gentoo like any other Linux distro as we did earlier. Tests will fail if run under grsecurity.
  1. Change our check to be 'if running under grsecurity and we're not root'. This is the best solution but requires us to have a good method for checking 'are we running with grsecurity?'.

comment:30 Changed 3 years ago by toralf

Just talked with guys in #gentoo-hardened and #grsecurity

There are much more security solutions flying around which let a test fail if the test case isn't run under an authorized user.

So in moment 2. would be a robust solution, a perfect solution would require more effort than it would be worth.

comment:31 Changed 3 years ago by atagar

Sounds good, made it so.

comment:32 Changed 3 years ago by toralf

installed that commit id at the relay - works fine.

thx

comment:33 Changed 3 years ago by atagar

Great - thanks for the help!

Note: See TracTickets for help on using tickets.