On Mon, Jul 29, 2024 at 1:55 PM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
>
> On Mon, Jul 29, 2024 at 6:29 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote:
> >
> > On Sat, Jul 27, 2024 at 4:55 AM Gong Ruiqi <gongruiqi1@xxxxxxxxxx> wrote:
> > >
> > >
> > > On 2024/07/26 21:43, Ondrej Mosnacek wrote:
> > > > On Thu, Jul 18, 2024 at 2:34 PM Gong Ruiqi <gongruiqi1@xxxxxxxxxx> wrote:
> > > >>
> > > >>
> > > >> On 2024/07/18 0:17, Paul Moore wrote:
> > > >>> ...
> > > >>>
> > > >>> Where (what distribution, version, etc.) did you see this problem?
> > > >>
> > > >> The problem occurred when I ran the testsuite on Fedora 40 with v6.6
> > > >> kernel, and it was the only failed testcase.
> > > >
> > > > Sorry for the delay... For some reason the test passes for me even
> > > > with cgroup v2 only and without the patch (also when run from a
> > > > regular user account with sudo). Do you happen to know what
> > > > circumstances are needed for it to fail when the cgroup is not
> > > > switched?
> > > >
> > >
> > > As the comment in the script says, a process need to be in the root
> > > cgroup in order to switch its scheduler policy to SCHED_{RR,FIFO}. So
> > > maybe in your case the shell process is already in the root cgroup?
> > >
> > > In my case I need to ssh to a Fedora VM, and that makes my shell process
> > > to be in a sub cgroup called /user.slice/.../XXX.scope (looks like some
> > > systemd stuff). And since /sys/fs/cgroup/cpu/tasks doesn't exit in the
> > > system with cgroup v2 only, the script skips moving the target process
> > > to the root cgroup, and therefore the subsequent test fails.
> >
> > In my case I ssh as root and end up in
> > /user.slice/user-0.slice/session-1.scope cgroup,
> > /sys/fs/cgroup/cpu/tasks also doesn't exist, and yet the test passes.
> > The same also happens when I ssh as a regular user (with cgroup
> > /user.slice/user-1000.slice/session-3.scope) and run the testsuite
> > with sudo. So there must be something more to it... maybe some kernel
> > config or sysctl setting?
>
> As a further data point, I also have been unable to reproduce the
> reported behavior.
> That said, since tasks doesn't exist, isn't the passing test a false
> negative (i.e. it isn't truly testing as intended)?
I don't think it is. The test wants to verify that it is possible to
change the scheduling policy with the SELinux permission and that it
is not possible without it - and it tests basically identical
conditions with the permission allowed and denied, so it indeed
verifies it correctly. The cgroup switch is just a preparation step so
that changing the policy to realtime policies can succeed at all. When
the test fully passes without switching the cgroup, then it just means
that the switch wasn't necessary for whatever reason.
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
