Opened 6 years ago

Last modified 6 years ago

#7433 defect new

test failures in -pair-14.0.0 due to root only access; test_tuntap.py

Reported by: I. Dleaney Owned by: I. Dleaney
Priority: normal Milestone:
Component: pair Keywords:
Cc: Mike Gilbert Branch:
Author:

Description (last modified by Jean-Paul Calderone)

Initially I thought this was a gentoo only issue, but no. In classes RealDeviceWithProtocolInformationTests and RealDeviceWithoutProtocolInformationTests, the suite fails persistently with see https://bugs.gentoo.org/show_bug.cgi?id=510834.

On some discussion it was clear that this would occur in any distro when run as user. It seems that the tests are written such that these 16 tests in those 2 classes need root permission to access the dev file. In gentoo the suite is run under portage with user level permission and thus the file is inaccessible.

Here is a patch.

Allows user to access /dev/net/tun

--- twisted/pair/test/test_tuntap.py.orig       2014-05-27 22:55:56.230232748 -0400
+++ twisted/pair/test/test_tuntap.py            2014-05-27 23:30:02.769956742 -0400
@@ -10,7 +10,7 @@
 import os
 import struct
 import socket
-from errno import EPERM, EBADF, EINVAL, EAGAIN, EWOULDBLOCK, ENOENT, ENODEV
+from errno import EPERM, EBADF, EINVAL, EAGAIN, EWOULDBLOCK, ENOENT, ENODEV, EACCES
 from random import randrange
 from collections import deque
 from itertools import cycle
@@ -582,8 +582,11 @@
         except OSError as e:
             # The device file may simply be missing.  The device file may also
             # exist but be unsupported by the kernel.
-            if e.errno in (ENOENT, ENODEV) and filename == b"/dev/net/tun":
-                raise SkipTest("Platform lacks /dev/net/tun")
+            if filename == b"/dev/net/tun":
+                if e.errno in (ENOENT, ENODEV):
+                    raise SkipTest("Platform lacks /dev/net/tun")
+                elif e.errno == EACCES:
+                    raise SkipTest("Access denied opening /dev/net/tun")
             raise

which sees the suite pass all fine

Change History (16)

comment:1 Changed 6 years ago by Jean-Paul Calderone

Description: modified (diff)

comment:2 Changed 6 years ago by Jean-Paul Calderone

Keywords: review added

comment:3 Changed 6 years ago by Jean-Paul Calderone

Keywords: review removed
Owner: set to I. Dleaney

What system configuration leads to the open failing with EACCES?

On first glance I thought this made sense if the user lacked read or write permission on /dev/net/tun but on further consideration it seems like that case would produce EPERM instead.

On a Debian Wheezy host an unprivileged user can open /dev/net/tun without error.

comment:4 Changed 6 years ago by radix

Is AppArmor involved?

comment:5 Changed 6 years ago by Mike Gilbert

What system configuration leads to the open failing with EACCES?

This occurs on a Gentoo Linux system with default udev rules from systemd upstream.

% ls -l /dev/net/tun
crw-rw-rw- 1 root root 10, 200 May 28 20:26 /dev/net/tun

The open(2) manpage says this in the errors section.

       EACCES The requested access to the file is not allowed, or search  per‐
              mission  is denied for one of the directories in the path prefix
              of pathname, or the file did not exist yet and write  access  to
              the  parent  directory  is  not allowed.  (See also path_resolu‐
              tion(7).)

       EPERM  The  O_NOATIME  flag was specified, but the effective user ID of
              the caller did not match the owner of the file  and  the  caller
              was not privileged (CAP_FOWNER).

comment:6 Changed 6 years ago by Mike Gilbert

Err... I have just realized that my ls output is in conflict with what I have stated.

idella: What are the permissions on /dev/net/tun on your system?

comment:7 Changed 6 years ago by Mike Gilbert

Ok, so this is probably being triggered by some sandboxing code that Gentoo's automated build platform (Portage) uses.

It uses an LD_PRELOAD hack to intercept calls to open(2), along with other syscalls, and denies write access to most paths outside the build directory.

I think we would prefer not to whitelist write access to /dev/net/tun if it can be avoided.

comment:8 Changed 6 years ago by Mike Gilbert

Cc: Mike Gilbert added

comment:9 Changed 6 years ago by Jean-Paul Calderone

Thanks for the extra information.

Ok, so this is probably being triggered by some sandboxing code that Gentoo's automated build platform (Portage) uses.

I see. Something we'll probably have a hard time reproducing in any of our tests environments, I suppose. :/

I think we would prefer not to whitelist write access to /dev/net/tun if it can be avoided.

Regardless, we'll probably try to fix this in Twisted. However, granting access to /dev/net/tun is the only way you'll be able to actually run these tests. Wouldn't it be better to run than to skip them? Is there another later stage where the full test suite can be run so you can see if Twisted works on Gentoo or not?

Thanks again.

comment:10 in reply to:  3 Changed 6 years ago by I. Dleaney

I was going to correct

"which sees the suite pass all fine"

to which sees the suite pass skip this 16 tests and not report 16 errors. However you seem to have already ascertained that.

"Something we'll probably have a hard time reproducing in any of our tests environments, I suppose. :/"

eeeer, yep.

"Wouldn't it be better to run than to skip them?"

In a word, yes or is it yep.

"Is there another later stage where the full test suite can be run so you can see if Twisted works on Gentoo or not?"

In a word, no. In an ebuild the testsuite is run from the source package PRIOR to install to the system. Sure you can run the testsuite post install which I get the impression is how it was designed, which means you're not running it from an ebuild. What we appear to have he is a horrible clash. It looks like 'we' will be looking at a possible 'in house' fix. Jury not in yet.

comment:11 Changed 6 years ago by Jean-Paul Calderone

Sure you can run the testsuite post install which I get the impression is how it was designed, which means you're not running it from an ebuild.

It so happens that I wrote these tests. ;) I have no experience at all with the Gentoo ebuild system so I guess it's not too surprising that I wrote something that is at odds with that system. Is there something about how these tests operate that I could change that would make them more ebuild-friendly?

comment:12 in reply to:  11 Changed 6 years ago by Mike Gilbert

Replying to exarkun:

It so happens that I wrote these tests. ;) I have no experience at all with the Gentoo ebuild system so I guess it's not too surprising that I wrote something that is at odds with that system. Is there something about how these tests operate that I could change that would make them more ebuild-friendly?

I don't think that there is anything wrong with the tests, but they are going to trigger EACCES from our sandbox in its default configuration.

You can trigger the same behavior by running chmod o-w /dev/net/tun.

I can whitelist that path in our sandbox, but we still get skips due to running as an unprivileged user.

[SKIPPED]
Permission to configure device denied

So, if you can add that code to handle EACCES from open, I can avoid adding a pointless entry to the sandbox whitelist. _

comment:13 Changed 6 years ago by Jean-Paul Calderone

I can whitelist that path in our sandbox, but we still get skips due to running as an unprivileged user.

The documentation explains how to grant the necessary access to unprivileged users in order to allow the tests to run and (hopefully) pass.

I'm pretty convinced that adding EACCES handling here is a good idea so I suspect that will happen soon. I am interested in having these tests actually pass in the ebuild, though, rather than just being successfully skipped. :) The more tests that run as part of the distro packaging process the better. That way we can field bug reports from the package maintainer instead of from all of the users who end up being the first ones to notice the functionality is broken.

comment:14 Changed 6 years ago by Mike Gilbert

The README mentions creating a tunnel device, and refers me to some configuration howto. Where do I find that?

comment:16 Changed 6 years ago by Mike Gilbert

Ok, so we are definitely not going to be able to do that automatically; our users would get rather upset if we start creating random devices on their systems.

The best I an do is print a warning and include some instructions that they can perform themselves.

Note: See TracTickets for help on using tickets.