Message-ID: <1e3d6e78-9b74-1da0-cb33-7caea5ce7a3a@linuxfoundation.org>
Date:   Fri, 28 Jul 2023 18:32:42 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     Anjali Kulkarni <anjali.k.kulkarni@...cle.com>
Cc:     Shuah Khan <shuah@...nel.org>,
        Liam Howlett <liam.howlett@...cle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH next 3/3] selftests:connector: Add root check and fix arg
 error paths to skip

On 7/28/23 18:19, Anjali Kulkarni wrote:
> 
> 
>> On Jul 28, 2023, at 4:00 PM, Shuah Khan <skhan@...uxfoundation.org> wrote:
>>
>> On 7/28/23 16:40, Anjali Kulkarni wrote:
>>>> On Jul 28, 2023, at 3:25 PM, Shuah Khan <skhan@...uxfoundation.org> wrote:
>>>>
>>>> On 7/28/23 15:59, Anjali Kulkarni wrote:
>>>>>> On Jul 28, 2023, at 2:41 PM, Shuah Khan <skhan@...uxfoundation.org> wrote:
>>>>>>
>>>>>> On 7/28/23 15:21, Anjali Kulkarni wrote:
>>>>>>>> On Jul 28, 2023, at 12:44 PM, Shuah Khan <skhan@...uxfoundation.org> wrote:
>>>>>>>>
>>>>>>>> On 7/28/23 13:06, Shuah Khan wrote:
>>>>>>>>> On 7/28/23 12:10, Anjali Kulkarni wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Jul 28, 2023, at 10:29 AM, Shuah Khan <skhan@...uxfoundation.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> proc_filter test requires root privileges. Add root privilege check
>>>>>>>>>>> and skip the test. Also fix argument parsing paths to skip in their
>>>>>>>>>>> error legs.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Shuah Khan <skhan@...uxfoundation.org>
>>>>>>>>>>> ---
>>>>>>>>>>> tools/testing/selftests/connector/proc_filter.c | 9 +++++++--
>>>>>>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/tools/testing/selftests/connector/proc_filter.c b/tools/testing/selftests/connector/proc_filter.c
>>>>>>>>>>> index 4fe8c6763fd8..7b2081b98e5c 100644
>>>>>>>>>>> --- a/tools/testing/selftests/connector/proc_filter.c
>>>>>>>>>>> +++ b/tools/testing/selftests/connector/proc_filter.c
>>>>>>>>>>> @@ -248,7 +248,7 @@ int main(int argc, char *argv[])
>>>>>>>>>>>
>>>>>>>>>>> if (argc > 2) {
>>>>>>>>>>> printf("Expected 0(assume no-filter) or 1 argument(-f)\n");
>>>>>>>>>>> - exit(1);
>>>>>>>>>>> + exit(KSFT_SKIP);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> if (argc == 2) {
>>>>>>>>>>> @@ -256,10 +256,15 @@ int main(int argc, char *argv[])
>>>>>>>>>>> filter = 1;
>>>>>>>>>>> } else {
>>>>>>>>>>> printf("Valid option : -f (for filter feature)\n");
>>>>>>>>>>> - exit(1);
>>>>>>>>>>> + exit(KSFT_SKIP);
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> + if (geteuid()) {
>>>>>>>>>>> + printf("Connector test requires root privileges.\n");
>>>>>>>>>>> + exit(KSFT_SKIP);
>>>>>>>>>>> + }
>>>>>>>>>>> +
>>>>>>>>>>
>>>>>>>>>> I am not sure why you have added this check? proc_filter does not need root privilege to run.
>>>>>>>>>>
>>>>>>>>> It failed for me when I ran it saying it requires root privileges.
>>>>>>>>> I had to run it as root.
>>>>>>>>
>>>>>>>> The following is what I see when I run the test as non-root
>>>>>>>> user:
>>>>>>>>
>>>>>>>> bind failed: Operation not permitted
>>>>>>>>
>>>>>>> Yes, that’s expected on a kernel which does not have the kernel patches submitted with this selftest installed on it.
>>>>>>> So this check for root needs to be removed.
>>>>>>
>>>>>> I will send v2 for this patch without root check. I should have
>>>>>> split the argument error paths and root check anyway.
>>>>>>
>>>>>> However, what is strange is if the test run by root, bind() doesn't fail.
>>>>>> This doesn't make sense to me based on what you said about bind() fails
>>>>>> if kernel doesn't support the new feature.
>>>>>>
>>>>> I didn’t say that - part of the changes introduced by the patches is to remove the root check and add some features on top of existing code.
>>>>
>>>> Okay. So what should happen if a root user runs this test on a kernel
>>>> that doesn't have the kernel patches submitted with this selftest
>>>> installed on it?
>>>>
>>> It will default to the behavior previous to my changes - that is it will report all events as opposed to a subset of events (which is the new feature added by my change)
>>
>> Okay. Sorry I am unable to follow this explanation. This test has just
>> been added in commit 73a29531f45fed6423144057d7a844aae46dad9d
> 
> Yes, the test has been added just now, but it also tests kernels previous to the new feature addition. So it is adding a selftest to kernels previous to this commit.
> That is, the connector module in kernel (before my changes) was sending to a listener user process messages for all process events - fork, exit, exec etc. This was only being done if the user process was run as root.
> With my changes, we add filtering based on an option added by user, which filters based on input and gives back to the user only fork, or only exit, or a combination of those. This is a new feature added. In addition to this filtering, we have also made the change to allow user process to be non-root when receiving these messages.
> 
>>
>> Can you please look at the usage for this test:
>>
>> - What should happen when kernel without filtering is run as
>> root or non-root
> 
> By kernel without filtering you mean a kernel without my patches? In that case, it should run only as root - non-root should fail. In this case, it falls back to default behavior before my change, where listener user process gets all messages related to process events. I have not tested this a lot, I am working on testing this on a kernel without my changes.
> 

Then you definitely need better messages when bind() fails
on kernels without the feature. It has to be clear to the
user why the test is exiting without running.

So this is what is needed:
- Check if the test can be run as non-root (whatever that means)
- It is still not clear to me if bind() fails does that mean the
   kernel doesn't doesn't support the new feature.

Since this test essentially behaves differently when the feature
is supported vs. not. So it has to behave consistently somehow
checking for the feature and report correctly.

thanks,
-- Shuah

Powered by blists - more mailing lists