Re: [PATCH 4/4] iotests/308: Test allow-other

From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH 4/4] iotests/308: Test allow-other
Date: Tue, 22 Jun 2021 17:32:43 +0200	[thread overview]
Message-ID: <42e9ae24-864d-fa53-3a04-2ac0df47b583@redhat.com> (raw)
In-Reply-To: <YNH86rBVVG2mJo/E@redhat.com>

On 22.06.21 17:08, Kevin Wolf wrote:
> Am 14.06.2021 um 16:44 hat Max Reitz geschrieben:
>> We cannot reasonably test the main point of allow-other, which is to
>> allow users other than the current one to access the FUSE export,
>> because that would require access to sudo, which this test most likely
>> will not have.  (Also, we would need to figure out some user/group that
>> is on the machine and that is not the current user/group, which may
>> become a bit hairy.)
>>
>> But we can test some byproducts: First, whether changing permissions
>> works (our FUSE code only allows so for allow-other=true), and second,
>> whether the kernel applies permission checks with allow-other=true
>> (because that implies default_permissions).
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
> This seems to have the problem that you mentioned:
>
> --- /home/kwolf/source/qemu/tests/qemu-iotests/308.out
> +++ 308.out.bad
> @@ -205,7 +205,9 @@
>            'writable': true,
>            'allow-other': true
>             } }
> -{"return": {}}
> +fusermount3: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
> +{"error": {"class": "GenericError", "desc": "Failed to mount FUSE session to export"}}
> +Timeout waiting for return on handle 2
>   (Invoking chmod)
>   Permissions post-chmod: 666
>   (Removing all permissions)
>
> Maybe it should be a separate test case that is skipped with
> user_allow_other is disabled.

Right.

>>   tests/qemu-iotests/308     | 91 ++++++++++++++++++++++++++++++++++++++
>>   tests/qemu-iotests/308.out | 47 ++++++++++++++++++++
>>   2 files changed, 138 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/308 b/tests/qemu-iotests/308
>> index f122065d0f..1b2f908947 100755
>> --- a/tests/qemu-iotests/308
>> +++ b/tests/qemu-iotests/308
>> @@ -334,6 +334,97 @@ echo '=== Compare copy with original ==='
>>   
>>   $QEMU_IMG compare -f raw -F $IMGFMT "$COPIED_IMG" "$TEST_IMG"
>>   
>> +echo
>> +echo '=== Test permissions ==='
>> +
>> +# Test that you can only change permissions on the export with allow-other=true.
>> +# We cannot really test the primary reason behind allow-other (i.e. to allow
>> +# users other than the current one access to the export), because for that we
>> +# would need sudo, which realistically nobody will allow this test to use.
>> +# What we can do is test that allow-other=true also enables default_permissions,
>> +# i.e. whether we can still read from the file if we remove the read permission.
> We already have other test cases that use sudo if available. Though I
> guess it means that these tests aren't run very often.

Yes, I know, but honestly I don’t really want to deal with user 
management either.  I had a paragraph about that in a preliminary 
version but decided to cut it, because, I thought it wouldn’t really matter.

That problem is that I’d need to run qemu-io as some different user, and 
the question is, who is a different user?  I suppose I could rely on 
“root” and “nobody” being valid users on any system, but I don’t think I 
can be sure that the user running the tests isn’t either of those.  So I 
would have to check whether the current user is “root”, and then run it 
as “nobody”, or otherwise run it as “root”, but that just seems like I’m 
getting in too deep for something that isn’t really useful anyway, 
because on developers’ machines, it will most likely be skipped anyway.

Max