On Thu, Feb 27, 2020 at 4:19 PM William Roberts <bill.c.roberts@xxxxxxxxx> wrote: > > On Thu, Feb 27, 2020 at 3:11 PM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > That just controls what is exported. The hidden_proto/hidden_def > > stuff is to ensure that when libselinux calls one of its own exported > > symbols, that symbol resolves to the actual libselinux implementation > > and not something provided by some other DSO earlier in the search > > path, which is otherwise possible. > > Sure, but do we actually care about that? > > If we actually do care, we could throw a script in the build to make sure > anything in the linker script map is not used internally. > > Right now, all this DSO hygiene and look up protection is opt-in, which > usually always results in missed cases. With the linker script, it's opt-out, > which is usually always how you want to do things. There are lots of cases where libselinux calls one of its own exported symbols, so you can't just prohibit that. -fno-semantic-interposition sounds like the right solution to me, and appears to be the default in clang. Dropping the hidden_def/hidden_proto stuff without enabling -fno-semantic-interposition could potentially break because libselinux could suddenly start using some external implementation of one of its own functions. Adding a map file and defaulting to hidden visibility would be a good idea but is separate.
