Re: [PATCH testsuite] policy: allow all test domains to inherit limits

On Tue, Aug 4, 2026 at 2:28 PM Stephen Smalley
<[email protected]> wrote:
>
> On Tue, Aug 4, 2026 at 3:25 AM Ondrej Mosnacek <[email protected]> wrote:
> >
> > Currently the "minimal" test domains aren't allowed to inherit resource
> > limits from other domains. However, that means that their resource
> > limits get reset to at most the init task's limits, which on some
> > distros and platforms (e.g. CentOS Stream 9 / RHEL 9 + ppc64le) isn't
> > enough to run the io_uring tests.
> >
> > Since the rlimitinh permission isn't tested by the testsuite, it can be
> > safely granted even to the minimal domains, so do just that.
> >
> > Signed-off-by: Ondrej Mosnacek <[email protected]>
> > ---
> >  policy/test_policy.if | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/policy/test_policy.if b/policy/test_policy.if
> > index ea15ca6..2a1a575 100644
> > --- a/policy/test_policy.if
> > +++ b/policy/test_policy.if
> > @@ -42,6 +42,7 @@ interface(`testsuite_domain_type_minimal',`
> >         testsuite_domain_type_common($1)
> >
> >         # minimal set of rules to substitute missing domain_type()
> > +       allow { domain testsuite_domain } $1:process { rlimitinh };
>
> Why are you allowing it to all "domain"?

Actually, scratch this patch... I was working under the assumption
that all `domain_type()` generally allows domains to inherit limits
from other domains, but that's not true (I saw that io_uring's policy
uses testsuite_domain_type_minimal() and automatically assumed that
it's the culprit).

I now think that just making sure that the RLIMIT_MEMLOCK soft limit
is set to the hard limit specifically in iouring.c is the right way to
fix this. Let me do some more research/testing and send a new patch...

>
> >         allow $1 proc_t:dir { search };
> >         allow $1 proc_t:lnk_file { read };
> >         allow $1 self:dir { search };
> > --
> > 2.55.0
> >
> >
>

-- 
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.