[LTP] [PATCH v1 3/4] syscalls/capset03: add new EPERM error test without CAP_SETPCAP

Yang Xu
2020-01-10T05:35:56Z

Hi!
> Hi!
>>> Also the CAP_DROP in the tst_test structure seems to be useless to me.
>>>
>>>
>>> Looking at man 7 capabilities, there are also transitions defined for
>>> what is supposed to happen when we change user id. It would make sense
>>> to write tests that capabilities are correctly dropped when UID changes
>>> from 0 to nonzero. Which is what this test is testing when executed as
>>> non-root, since the transition from 0 to nonzero must have happened
>>> somewhere when user has logged in.
>> In man 7 capabilities " Effect of user ID changes on capabilities",
>> I see transitions between 0 and nonzero user IDs. But it is about
>> capabilities??not about capset syscall. I think we should add these
>> cases(user ID changes on capabilities) into kernel/security (such as
>> cap_bound or filecaps). In capset, we can only test capset various EPERM
>> error as kernel sercurity/commoncap.c cap_capset function.
>> ---------------------------------
>> if (cap_inh_is_capped() &&
>> !cap_issubset(*inheritable,
>> cap_combine(old->cap_inheritable,
>> old->cap_permitted)))
>> /* incapable of using this inheritable set */
>> return -EPERM;
>>
>> if (!cap_issubset(*inheritable,
>> cap_combine(old->cap_inheritable,
>> old->cap_bset)))
>> /* no new pI capabilities outside bounding set */
>> return -EPERM;
>>
>> /* verify restrictions on target's new Permitted set */
>> if (!cap_issubset(*permitted, old->cap_permitted))
>> return -EPERM;
>>
>> /* verify the _new_Effective_ is a subset of the _new_Permitted_ */
>> if (!cap_issubset(*effective, *permitted))
>> return -EPERM;
>> ---------------------------------
>
> Indeed these does not belog under setcap(). Maybe we could add these
> checks under setuid tests, since we are testing side efect of setuid.
> But having these under security/ would work as well.Maybe put them in setuid is better because I don't know a good
directory name for them in security(such as user_change_cap). Anyway, I
will list them in my todo.
>
>> Also, if we only run under root, CAP_DROP(CAP_SETPCAP) is needed to
>> reproduce this EPERM error.
>
> Isn't the first thing that the test does to remove all capabilities but
> CAP_KILL? Why do we need to drop anything beforehand?
Yes, you are right. I forgot it. I will remove this drop and also used
guarded buffer for the other capset cases .
>