Re: [PATCH][RFC] selinuxfs: saner handling of policy reloads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 16, 2023 at 9:31 AM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
> On Thu, Nov 16, 2023 at 8:16 AM Stephen Smalley
> <stephen.smalley.work@xxxxxxxxx> wrote:
> > On Wed, Nov 15, 2023 at 8:35 AM Stephen Smalley
> > <stephen.smalley.work@xxxxxxxxx> wrote:
> > > On Tue, Nov 14, 2023 at 5:24 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Tue, Nov 14, 2023 at 3:57 PM Stephen Smalley
> > > > <stephen.smalley.work@xxxxxxxxx> wrote:
> > > > > On Mon, Nov 13, 2023 at 11:19 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > > > > On Mon, Oct 16, 2023 at 6:08 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > [
> > > > > > > That thing sits in viro/vfs.git#work.selinuxfs; I have
> > > > > > > lock_rename()-related followups in another branch, so a pull would be more
> > > > > > > convenient for me than cherry-pick.  NOTE: testing and comments would
> > > > > > > be very welcome - as it is, the patch is pretty much untested beyond
> > > > > > > "it builds".
> > > > > > > ]
> > > > > >
> > > > > > Hi Al,
> > > > > >
> > > > > > I will admit to glossing over the comment above when I merged this
> > > > > > into the selinux/dev branch last night.  As it's been a few weeks, I'm
> > > > > > not sure if the comment above still applies, but if it does let me
> > > > > > know and I can yank/revert the patch in favor of a larger pull.  Let
> > > > > > me know what you'd like to do.
> > > > >
> > > > > Seeing this during testsuite runs:
> > > > >
> > > > > [ 3550.206423] SELinux:  Converting 1152 SID table entries...
> > > > > [ 3550.666195] ------------[ cut here ]------------
> > > > > [ 3550.666201] WARNING: CPU: 3 PID: 12300 at fs/inode.c:330 drop_nlink+0x57/0x70
> > > >
> > > > How are you running the test suite Stephen?  I haven't hit this in my
> > > > automated testing and I did another test run manually to make sure I
> > > > wasn't missing it and everything ran clean.
> > > >
> > > > I'm running the latest selinux-testsuite on a current Rawhide system
> > > > with kernel 6.7.0-0.rc1.20231114git9bacdd89.17.1.secnext.fc40 (current
> > > > Rawhide kernel + the LSM, SELinux, and audit dev trees).
> > >
> > > Technically this was with a kernel built from your dev branch plus
> > > Ondrej's selinux: introduce an initial SID for early boot processes
> > > patch, but I don't see how the latter could introduce such a bug. Will
> > > retry without it.
> >
> > Reproduced without Ondrej's patch; the trick seems to be accessing
> > selinuxfs files during the testsuite run (likely interleaving with
> > policy reloads).
> > while true; do cat /sys/fs/selinux/initial_contexts/kernel ; done &
> > while running the testsuite seems to trigger.
> > Could also try while true; do sudo load_policy; done & in parallel
> > with the above loop.
> > In any event, will retry with Al's updated branch with the fix he proposed.

Ah ha!  That would definitely explain why I didn't see it in my test
runs, I generally don't do anything on the test system when the test
is running.

> So far not showing up with Al's updated for-selinux branch. Difference
> between that and your dev branch for selinuxfs is what he showed
> earlier in the thread (pardon the whitespace damage) ...

I just updated the selinux/dev branch with the change from Al's tree.
Considering the minor nature of the fix, and the other patches
currently in flight on the list, I just updated the original commit
(with a note) and did a force push; I doubt that will cause issues
with anyone, but as I try to avoid force pushes on the */dev branches
I thought it was worth mentioning.

Thanks everyone!

-- 
paul-moore.com




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux