On Thu, Feb 27, 2020 at 3:31 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > 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. Interesting to note. > 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. Conjecture. > Adding a map file and defaulting to hidden visibility would be a good > idea but is separate. IIUC, not really, the current code attempts to limit our exported symbols. You would need both the compiler option and a map file to keep functional parity with whats there. Which is fine, that's easy enough to do and should be some welcome housekeeping.
