> What system are you on where you run libsemange without glibc, just curious? All Gentoo machines, Gentoo musl. :) > I am not opposed to adding an implementation for basename where the > input can be read only for non-glibc, but this patch doesn't work: > Per the man page, https://man7.org/linux/man-pages/man3/basename.3.html, > basename("/") should return "/", this one return "\0" > basename("/usr/"); should return "usr", this returns "\0". > There are two ways you could approach this: > 1. If you wanted to do an implementation, I would add it to > utilities.c/h and call it something other than basename so we don't > get any odd issues with it choosing the one from the headers over the > macro. Perhaps libsemange_basename(). On glibc systems this would just > call basename directly and on non-glibc systems do the implementation > with your own logic. > 2. Just copy the path into a modifiable buffer on non-glibc systems > > I would do both approaches. Create a utility routine that calls > basename for glibc and for non-glibc just copies it to a modifiable > buffer and then calls basename over rolling our own and the bugs > associated with it, also add a unit test for this. This would keep the > logic in one place and be dirt simple. FWIW, glibc's basename appears to be really trivial: char * __basename (const char *filename) { char *p = strrchr (filename, '/'); return p ? p + 1 : (char *) filename; } > selinux_policy_root() returns a const char *, > the usage in direct_api.c path is a char *, so we only need one spot > changed and that can just be a simple > copy to an intermediate buffer or am I missing something else here > you're pointing out? Oh good point, we're just missing a header (libgen.h). I suppose then it is just a simple copy to an intermediate buffer, I'll send an updated patch shortly. Thanks, Rahul
