> On Jul 28, 2023, at 5:32 PM, Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On 7/28/23 18:19, Anjali Kulkarni wrote:
>>> On Jul 28, 2023, at 4:00 PM, Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> On 7/28/23 16:40, Anjali Kulkarni wrote:
>>>>> On Jul 28, 2023, at 3:25 PM, Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>>
>>>>> On 7/28/23 15:59, Anjali Kulkarni wrote:
>>>>>>> On Jul 28, 2023, at 2:41 PM, Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>>>>
>>>>>>> On 7/28/23 15:21, Anjali Kulkarni wrote:
>>>>>>>>> On Jul 28, 2023, at 12:44 PM, Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx>
>>>>>>>>>>>> ---
>>>>>>>>>>>> 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)
Not sure what you mean by this?
> - It is still not clear to me if bind() fails does that mean the
> kernel doesn't doesn't support the new feature.
It means you need to be root to run the program - this is the expected behavior on kernels which do not have my change(to allow non-root access). So, today if you wrote a program to test basic connector code without filtering(without my changes) - this is how it would respond. This is a check in the kernel(without my changes) which makes bind fail if user is non-root. With my change this change has been effectively removed.
Anjali
>
> 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
