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. -- Respectfully, William C Roberts _______________________________________________ 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.
