With emerge mc, and with many other packages, I get this error message: QA Notice: /usr/lib/mc/cons.saver is setXid, dynamically linked and using lazy bindings. This combination is generally discouraged. Try: LDFLAGS='-Wl,-z,now' emerge mc This issue was earlier discussed at: http://lwn.net/Articles/99137/ To quote from a comment: "Is the decision to use RDLT_LAZY hardcoded in /lib/ld-linux.so.2 ? Maybe it would make sense to change that to the equivalent of RTLD_NOW for SUID apps for more deterministic behavior, since the delay caused by LD_DEBUG abuse only increases the already present delay for dynamic symbol resolution in the middle of an operation." Now, wouldn't it make sense to fix this in glibc, as this reader says? Reproducible: Always Steps to Reproduce: 1. Emerge any package building a +s executable and not using early bindings for it in linker settings.
While this sounds very ideal this change would prevent Xorg from starting. There is a few cases where setXid is used with lazy bindings. It's not the right thing todo but it's just the way things work now.
As stated, at this point in time, we can't reasonably do this.
actually we can, i have such a patch to do so
Created attachment 85428 [details, diff] setuid-bind-now.patch
*** Bug 121758 has been marked as a duplicate of this bug. ***
*** Bug 130934 has been marked as a duplicate of this bug. ***
*** Bug 147871 has been marked as a duplicate of this bug. ***
*** Bug 76210 has been marked as a duplicate of this bug. ***
A glibc bug about this was marked as a duplicate of this. But there was a patch attached, solving the problem. Is this patch going to be submitted or should i remove "stricter" from my FEATURES since "it's just the way things work now"?
*** Bug 149635 has been marked as a duplicate of this bug. ***
*** Bug 150972 has been marked as a duplicate of this bug. ***
*** Bug 151395 has been marked as a duplicate of this bug. ***
*** Bug 138817 has been marked as a duplicate of this bug. ***
we had a discussion a while ago among hardened/security but never came to a resolution we're dropping the bindnow-flags from ebuilds and the warning has been removed from portage ... the only bit left is whether we want this functionality in our glibc (if only for USE=hardened)
(In reply to comment #14) > we had a discussion a while ago among hardened/security but never came to a > resolution > > we're dropping the bindnow-flags from ebuilds and the warning has been removed > from portage ... the only bit left is whether we want this functionality in our > glibc (if only for USE=hardened) > So...do we? :) This has been open for ages and it would be nice for it to come to a conclusion.
hardened does not care about this and never really has. We already link -z now -z relro by default. Being that there would be no clear/nice way to for *libc to handle executables such as X which are +s and require -z lazy bindings. I don't see a point in doing anything here. "/etc/suid-bind-now/" while works. It's just not pretty.
Since hardened doesn't care for this, then I think this time we can really close it.
