Re: [PATCH 1/2] libsepol/dso: drop hidden_proto and hidden_def

[William Roberts <bill.c.roberts@gmail.com>]

On Tue, Mar 10, 2020 at 3:09 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Mon, Mar 9, 2020 at 11:25 AM <bill.c.roberts@gmail.com> wrote:
> >
> > From: William Roberts <william.c.roberts@intel.com>
> >
> > 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@intel.com>
>
> 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.