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

[Cyril Hrubis]

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.

> 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?

-- 
Cyril Hrubis
chrubis@suse.cz