On Fri, Apr 12, 2019 at 6:02 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> On Fri, Apr 12, 2019 at 3:31 PM Dominick Grift <dac.override@xxxxxxxxx> wrote:
> > Paul Moore <paul@xxxxxxxxxxxxxx> writes:
> >
> > > On Fri, Apr 12, 2019 at 12:37 PM Richard Haines
> > > <richard_c_haines@xxxxxxxxxxxxxx> wrote:
> > >> On Fri, 2019-04-12 at 10:46 -0400, Paul Moore wrote:
> > >> > On Thu, Apr 11, 2019 at 6:07 PM Paul Moore <paul@xxxxxxxxxxxxxx>
> > >> > wrote:
> > >> > > On the negative side I realized when playing with your test changes
> > >> > > that I wasn't building BINDERFS in my test kernels - oops. I'm
> > >> > > fixing
> > >> > > that now, but I might not get a chance to do another test until
> > >> > > tomorrow; at least I can verify that your BINDERFS testing logic
> > >> > > works
> > >> > > :)
> > >> >
> > >> > I rebuilt my test kernel (the latest "secnext" builds have it) with
> > >> > BINDERFS only to realize that Fedora Rawhide doesn't seem to ship
> > >> > /usr/include/linux/android/binderfs.h so I manually copied the file
> > >> > from the kernel-devel package only to run into this when building the
> > >> > new binder tests:
> > >> >
> > >> > # make
> > >> > cc -DHAVE_BINDERFS check_binder.c binder_common.c binder_common.h
> > >> > -lselinux -lrt -o check_binder
> > >> > binder_common.c: In function ‘cmd_name’:
> > >> > binder_common.c:35:7: error: ‘BR_TRANSACTION_SEC_CTX’ undeclared
> > >> > (first use in t
> > >> > his function); did you mean ‘BC_TRANSACTION_SG’?
> > >> > 35 | case BR_TRANSACTION_SEC_CTX:
> > >> > | ^~~~~~~~~~~~~~~~~~~~~~
> > >> > | BC_TRANSACTION_SG
> > >> > binder_common.c:35:7: note: each undeclared identifier is reported
> > >> > only once for
> > >> > each function it appears in
> > >> > binder_common.c: In function ‘print_trans_data’:
> > >> > binder_common.c:126:23: error: ‘FLAT_BINDER_FLAG_TXN_SECURITY_CTX’
> > >> > undeclared (f
> > >> > irst use in this function)
> > >> > 126 | obj->flags & FLAT_BINDER_FLAG_TXN_SECURITY_CTX ?
> > >> > "YES" : "NO");
> > >> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >> > make: *** [<builtin>: check_binder] Error 1
> > >> > # grep "BR_TRANSACTION_SEC_CTX" *
> > >> > binder_common.c: case BR_TRANSACTION_SEC_CTX:
> > >> > binder_common.c: return "BR_TRANSACTION_SEC_CTX";
> > >> > service_provider.c: case BR_TRANSACTION_SEC_CTX: {
> > >> > # grep "BR_TRANSACTION_SEC_CTX" /usr/include/linux/android/binderfs.h
> > >> > # grep "BR_TRANSACTION_SEC_CTX" /usr/include/linux/android/binder.h
> > >> >
> > >> > ... and that's when I stopped playing with this. If it helps, I
> > >> > pulled my binderfs.h file from a current Rawhide kernel. What are
> > >> > you
> > >> > using to run these tests?
> > >> >
> > >> > At the very least, I'm thinking we'll also want to include some notes
> > >> > in the README.md file under the "Optional Prerequisites" section
> > >> > about
> > >> > how to get this running with BINDERFS.
> > >>
> > >> The BR_TRANSACTION_SEC_CTX is defined in an updated binder.h file, so
> > >> you need both binder.h and binderfs.h from devel.
> > >>
> > >> I guess I must have copied them over by hand as I tested on rawhide.
> > >> I'll add a note in the README.md file.
> > >
> > > Okay, that solved the problem, thanks.
> > >
> > > I just noticed that the kernel-headers package on my Rawhide systems
> > > are *really* old. I suspect this may be due to the fact that I'm not
> > > running Fedora Rawhide kernels and thus my currently installed kernel
> > > packages don't match what is present in the main Rawhide repos; this
> > > problem might be limited to just me (and anyone exclusively running
> > > the secnext kernels on their system).
> > >
> > > Can anyone with a Rawhide system confirm if they have the
> > > /usr/include/linux/android/binderfs.h header file?
> >
> > [root@brutus ~]# rpm -qf /usr/include/linux/android/binderfs.h
> > kernel-headers-5.1.0-0.rc2.git1.1.fc31.x86_64
>
> Thanks.
>
> I realized today that last summer Fedora changed how they package the
> kernel headers and thus I need to update how I build my test kernels.
> As an aside, I don't get why the change was made, this new process for
> building the kernel-headers package is *really* convoluted ... and
> broken if you are using a custom %buildid (which I do for "secnext"
> builds), but that's a different issue.
With the header issue sorted out, the tests is now running clean for
me so I just merged it into the selinux-testsuite master branch.
Thanks for your patience on this.
--
paul moore
www.paul-moore.com
