[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Testing for FUSE in ci tests



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.

$ 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. 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)?

-- 
Antonio Terceiro <terceiro@debian.org>

Attachment: signature.asc
Description: Digital signature


Reply to: