Antonio Terceiro <terce...@debian.org> writes:
> On Thu, Jul 10, 2014 at 11:06:59PM -0700, Nikolaus Rath wrote:
>> On Thu, 17 Apr 2014 15:15:00 -0300, Antonio Terceiro wrote:
>> > On Wed, Apr 16, 2014 at 06:49:41PM -0700, Nikolaus Rath wrote:
>> >> Currently the S3QL CI tests fail because the test runner does not have
>> >> permission to access the /dev/fuse device
>> >> (http://ci.debian.net/data/unstable-amd64/packages/s/s3ql/2014-04-10.log).
>> >>
>> >> Nothing wrong with that, but the test already goes out of its way to
>> >> determine if it ought to be able to use FUSE, or if the test should be
>> >> skipped. It checks:
>> >>
>> >> - Is there a fusermount executable?
>> >> - Is there a /dev/fuse device?
>> >> - Are we root, or is the fusermount executable setuid root?
>> >> - Can we execute fusermount -V without getting an error?
>> >>
>> >> It seems all these preconditions are fulfilled, yet fuse access is
>> >> not allowed.
>> >>
>> >> Does someone know a test that will (even more) reliably determine if
>> >> fuse is available or not?
>> >
>> > I guess a more precise description of what exactly the ci.debian.net
>> > test runner is would help figuring this out. So current ci.debian.net
>> > runs test suites on schroot sessions with the following configuration:
>> [...]
>>
>> This looks perfectly normal, /dev is just bind mounted to the schroot
>> session.
>>
>> Is it possible that the /dev/fuse on the host system has non-default
>> permissions? On current testing and unstable, /dev/fuse is 666 by
>> default.
>
> /dev/fuse is 600 on the host, but I never did anything explicitly about
> it.
Ah, ok. Then I can check for that and have the fuse test at least be
skipped rather than failing.
> $ ls -l /dev/fuse
> crw------T 1 root root 10, 229 May 2 15:12 /dev/fuse
> $ dpkg-query --show udev
> udev 175-7.2
>
> I understand that fuse-utils is reponsible for setting the proper
> permissions for /dev/fuse, and it is indeed not installed on the host.
But fuse-utils is required by the package being tested. Shouldn't that
cause its installation prior to the test run and fix up the permissions?
> I could make debci depend on fuse-utils, but maybe the tests that
> depend on devices in /dev/ should be marked as requiring kernel-level
> isolation instead (we should get to the point of running on actual
> vm's at some point)?
I don't see why using /dev/fuse should require kernel-level
isolation.. but you are probably right for most other stuff in /dev.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k37j2nbq....@vostro.rath.org
