I'm the proxied maintainer for tsm. tsm-7.1.0.0.ebuild has a line which reads “fperms -R g+rX,o-rx /opt/tivoli”. It also installs /usr/lib64/libtsmxerces-c.so.28 and /usr/lib64/libtsmxerces-depdom.so.28 as symlinks into /opt/tivoli/tsm/client/api/bin64/, so normal users outside the tsm group can't read those files. When ldconfig sees a symlink to a file it can't stat, it considers that a stale symlink and will try to remove it. Emerging dev-libs/xapian-1.3.1-r1 with FEATURES=userpriv, this causes a sandbox access error since the configure script of that package calls “/sbin/ldconfig -N -X -v”. I'll attach a patch to address this as soon as I have a number for this bug here.
Created attachment 375244 [details, diff] Patch to fix permissions Please apply this patch to the ebuild while revbumping it to -r1. The rationale why this is safe is as follows: while most things in that directory will be of little use to users which are not in the tsm group, only the suid root binary dsmtca could be actually harmful. So everything else may stay world readable, to avoid the kind of issue described above. Have to do fix permissions of possibly existing dirs in pkg_postinst due to bug #58611 resp. #141619 resp. #396153.
So, is this relevant to xapian and ebuild maintainers or not? If not, feel free to remove. Thanks.
(In reply to Johan Bergström from comment #2) > So, is this relevant to xapian and ebuild maintainers or not? Hmmm. There are several packages which could take action to resolve the immediate problem. I've ordered the list by how reasonable I consider each approach to be, from most to least reasonable: 1. tsm should be changed to not install read-restricted libs in /usr/lib That might cause problems with other packages, and might confuse other stuff, and I can't see a reason just now why this kind of restriction should be neccessary. 2. glibc might tweak its ldconfig so that no unlink is attempted if -X is given After all, -X requests the tool to not update symlinks, and I for one would expect it to leave ALL symlinks alone in that case. Furthermore, I'd expect it to only declare a symlink dead if it failed to stat the file in question due to ENOENT. Simply removing a symlink for any kind of error seems wrong. But all of this is more of an upstream kind of bug, and I'll report it there. 3. sandbox might be changed to not prevent an unlink which would fail in any case That would require sandbox to reliably detect situations where an unlink is bound to fail due to lack of permissions, and to always have unlink return EPERM in those cases without actually logging a sandbox violation. This would make sense if such issues were to happen more often, but seems overkill for this single incident. 4. xapian configure could be tweaked to not call ldconfig I think that running configure should never attempt to remove stuff on my system. In that sense, the xapian configure script executing ldconfig is bad. But perhaps the xapian devs had the same misconception of -X that I had. In that case, the problem is again with glibc. It is up to xapian (ebuild or upstream maintainers) to decide whether they want to work around that bug or not. To decide that, one would have to understand what made them call ldconfig in the first place. I don't. > If not, feel free to remove. I'd say, in the light of the above, decide for yourself whether you intend to do anything about it right now. I definitely want the tsm issue addressed and my patch applied. Apart from that, I suggest you keep this issue in mind in case anyone else reports an access violation with a less thorough investigation of causes. But I won't mind you leaving this bug without taking any action on the xapian side.
I would apply the tsm patch but will CC sandbox/glibc people to know if they have other suggestions
(In reply to Martin von Gagern from comment #3) > 2. glibc might tweak its ldconfig so that no unlink is attempted if -X is > given > > After all, -X requests the tool to not update symlinks, and I for one would > expect it to leave ALL symlinks alone in that case. Furthermore, I'd expect > it to only declare a symlink dead if it failed to stat the file in question > due to ENOENT. Simply removing a symlink for any kind of error seems wrong. > But all of this is more of an upstream kind of bug, and I'll report it there. Filed as https://sourceware.org/bugzilla/show_bug.cgi?id=16871
(In reply to Martin von Gagern from comment #3) (3) most likely isn't going to happen. bad code is bad code. we've caught bad bugs in the past that wouldn't cause a problem when run as a user, but would have caused problems when run as root. (4) it's rare for packages to have a valid reason to call ldconfig. so if it can be deleted, then that would be a good route to go regardless of anything else.
(In reply to SpanKY from comment #6) > (4) it's rare for packages to have a valid reason to call ldconfig. so if > it can be deleted, then that would be a good route to go regardless of > anything else. https://github.com/xapian/xapian/commit/5b241d9a09bed8142fa9412234a1621c1bf35293 resp. http://trac.xapian.org/changeset/10892/svn seems to be the relevant commit. The way I see it, it should be possible to simply remove that whole case…esac block. Apparently sys_lib_dlsearch_path_spec gets picked up by autotools in any case. Changes to xapian-core.spec.in indicate: # In the 1.1.0 branch, Xapian uses libtool 2.2.x which allows us to override # libtool's sometimes conservative take on which directories are in the default # dynamic linker search path, so we no longer incorrectly try to set rpath for # /usr/lib64. Hence there's no longer a need to run "autoreconf --force" here # and it's better not to as it avoids having to cope with incompatibilities # with older versions of the autotools which older distros have. To me this reads like the change might be needed if a) installing into strange locations of b) the use of /usr/lib64 causes trouble. Neither should be the case on Gentoo, so as far as I can see it, removing that block should work.
Created attachment 380072 [details, diff] Make ldconfig less eager to unlink stuff 1. Pacho, please apply my patch from comment #1 and revbump tsm. 2. glibc maintainers, will you accept the attached (untested) patch to ldconfig? 4. Johan, have you made up your mind whether you want to address this in xapian?
Thanks for following up. I'll look into removing the ldconfig call and see how that goes.
+*tsm-7.1.0.0-r1 (05 Jul 2014) + + 05 Jul 2014; Pacho Ramos <pacho@gentoo.org> +tsm-7.1.0.0-r1.ebuild, + -tsm-7.1.0.0.ebuild: + Bug 508052: directories used to be too restrictive, have to widen perms + (thanks to Martin von Gagern) +
