On 09/29/2016 03:27 PM, William Roberts wrote: > On Thu, Sep 29, 2016 at 3:15 PM, William Roberts > <bill.c.roberts@xxxxxxxxx> wrote: >> On Thu, Sep 29, 2016 at 2:54 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >>> On 09/29/2016 02:46 PM, William Roberts wrote: >>>> On Thu, Sep 29, 2016 at 2:44 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >>>>> On 09/29/2016 02:15 PM, William Roberts wrote: >>>>>> On Thu, Sep 29, 2016 at 2:08 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >>>>>>> On 09/29/2016 02:02 PM, william.c.roberts@xxxxxxxxx wrote: >>>>>>>> From: William Roberts <william.c.roberts@xxxxxxxxx> >>>>>>>> >>>>>>>> Provide stubs to the public boolean API that always returns -1. >>>>>>>> >>>>>>>> On Android, boolean symbols are needed for: >>>>>>>> external/ltrace/sysdeps/linux-gnu/trace.c >>>>>>> >>>>>>> Is this really worth doing? >>>>>> >>>>>> It's this or disabling that selinux via #define, which that source has >>>>>> HAVE_LIBSELINUX. >>>>>> >>>>>> But it would seem confusing IMHO to have a libselinux.so, so one would >>>>>> set HAVE_LIBSELINUX=1, >>>>>> and you're getting link errors. >>>>> >>>>> Maybe I don't understand. Obviously it builds today with >>>>> external/libselinux without requiring this change. Why do we need this now? >>>>> >>>> >>>> Richard Haines was doing further testing, and was building a different >>>> lunch target for the >>>> arm emulator and hit this issue. I have only tested x86_64 emulator. >>> >>> No, I mean that this is not required in external/libselinux (the Android >>> fork) today. So why is it needed here? The Android fork builds >>> src/booleans.c for the target. It doesn't hurt anything to leave the >>> code there. The underlying kernel interface via selinuxfs still exists. >>> There just won't be any booleans in the policy. >>> >> >> The target builds a modified booleans, if use booleans as is, we start >> down the config c file >> rabbit hole... >> >> external/selinux/libselinux/src/booleans.c:100: error: undefined >> reference to 'selinux_booleans_subs_path' >> external/selinux/libselinux/src/booleans.c:388: error: undefined >> reference to 'selinux_booleans_path' >> external/selinux/libselinux/src/booleans.c:529: error: undefined >> reference to 'selinux_booleans_path' >> external/selinux/libselinux/src/booleans.c:545: error: undefined >> reference to 'selinux_booleans_path' >> clang++.real: error: linker command failed with exit code 1 (use -v to >> see invocation) >> >> I can take a look at that and see how much of a PITA it would be to >> pull that in. > > external/selinux/libselinux/src/selinux_config.c:100: error: undefined > reference to 'fgets_unlocked' > external/selinux/libselinux/src/selinux_config.c:100: error: undefined > reference to 'fgets_unlocked' > external/selinux/libselinux/src/selinux_config.c:231: error: undefined > reference to 'require_seusers' > external/selinux/libselinux/src/selinux_config.c:231: error: undefined > reference to 'load_setlocaldefs' > > fgets should be easy enough > load_setlocaldefs is an exported integer value used in init_selinux_config() > require_seusers is another exported int form seusers.c > > I was figuring since we don't use any bools, to keep the size down, > just stubbing dummies is the > easiest route. > > We could do something like STATIC_CONFIG and just stub in what things > need and return the explicit paths. Never mind, I'll take your original patch. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
