On Tue, Mar 10, 2020 at 3:09 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Mon, Mar 9, 2020 at 11:25 AM <bill.c.roberts@xxxxxxxxx> wrote: > > > > From: William Roberts <william.c.roberts@xxxxxxxxx> > > > > libsepol already has a linker script controlling it's exports, so this > > patch has a net 0 affect, with the exception that internal callers of > > external routines, which there could be 0 of, could potentially call a > > non-libsepol routine depending on library load order. > > > > Additionally, verify that nothing changed in external symbols as well: > > > > This was checked by generating an old export map (from master): > > nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > old.map > > > > Then creating a new one for this library after this patch is applied: > > nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > new.map > > > > And diffing them: > > diff old.map new.map > > > > Signed-off-by: William Roberts <william.c.roberts@xxxxxxxxx> > > I get the following differences when I do the same: > > $ diff oldmap newmap > 62a63 > > sepol_context_to_sid > 93a95 > > sepol_ibendport_sid > 117a120 > > sepol_ibpkey_sid > 163a167 > > sepol_msg_default_handler > 194a199 > > sepol_node_sid > 240a246 > > sepol_port_sid > > Looks like these were marked hidden previously but get pulled into the > map through wildcards if that isn't retained. > Maybe we should drop wildcards from the version script. Interesting, i'm glad you double checked that. I wonder why my diff came out clean, perhaps I fat fingered something or didn't have a clean environment. Yeah pulling out those wild cards is probably smart anyway, even if the diff did come back clean.
