| Summary: | Portage should not abort on trivial rpath issues, only on serious ones | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Thierry Carrez (RETIRED) <koon> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | CC: | bugs |
| Priority: | High | ||
| Version: | 2.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | ebuild.sh diff to fix insecure rpaths | ||
|
Description
Thierry Carrez (RETIRED)
2006-01-01 03:38:51 UTC
I think it would be to risky to not abort. Users and devs often rm -rf /var/tmp/portage and wont always remeber todo rm -rf /var/tmp/portage/* How about if chrpath is installed (and fixrpaths is in FEATURES?) we autofix the elf in question and not abort? maybe something like this Index: ebuild.sh =================================================================== --- ebuild.sh (revision 2515) +++ ebuild.sh (working copy) @@ -1042,7 +1042,13 @@ echo " http://bugs.gentoo.org/81745" echo "${f}" echo -ne '\a\n' - insecure_rpath=1 + if hasq fixrpaths ${FEATURES} && type -p chrpath > /dev/null; then + for x in ${f}; do + chrpath -d "${x}" + done + else + insecure_rpath=1 + fi fi # Check for setid binaries but are not built with BIND_NOW Or we could make it autofix whenever chrpath is installed and stricter is not set.
+ if ! hasq stricter ${FEATURES} && type -p chrpath > /dev/null; then
yeah, assuming that /var/tmp/portage will always exist and be restricted to portage users is too much as solar points out, a lot of people casually punt it I agree the right solution would be to create bugs and to fix them quickly, but that doesn't happen. Having the autofix workaround could limit the impact on stable portage, but it would still not look too good. The real challenge is to fix them, as most people (me included) don't have the slightest clue on how to do it. So they pile up, unfixed... (In reply to comment #4) > The real challenge is to fix them, as most people (me included) don't have the > slightest clue on how to do it. So they pile up, unfixed... So what do you want todo here? (In reply to comment #5) > So what do you want todo here? Maybe have someone clueful coordinate the bugs in the newly-created "Runpath issues" component, meaning assigning severity based on accessibility of the vulnerable path, helping maintainers to fix them, making them care about them and educating them in case of need... The usual suspects^H^H^HGLSA Coordinators seem to be pretty clueless beyond severity rating so we might need your help. vapier seems to have taken a few of those already, and mcummings could be persuaded to solve once and for all the Perly things which seem to represent about half of the issues... If we can solve them quickly enough, then the autofix may not be needed... But I would still provide some simple way for users to override the blocking. Like a FEATURE="IWontremoveVarTmpPortageAndITrustMyPortageGroup" Personally a "big scary warning" saying to file a bug is about the best you should expect. Portage shouldn't be dying due to insecure runpath issues. Especially when there is no current way to get around it (besides gutting that stuff from ebuild.sh). In the end most users aren't going to be able to fix anything, they will just report on it, and you will have to file bugs against the maintainers or fix it yourself, thats just how it will end up ;) I don't particularly want to see another "FEATURE" just to cover this case either. It's a bit sloppy. > Personally a "big scary warning" saying to file a bug is about the best you > should expect. Portage shouldn't be dying due to insecure runpath issues. it should actually > Especially when there is no current way to get around it (besides gutting that > stuff from ebuild.sh). `scanelf -Xr` fixes insecure runpaths now (In reply to comment #8) > > Personally a "big scary warning" saying to file a bug is about the best you > > should expect. Portage shouldn't be dying due to insecure runpath issues. > > it should actually > > > Especially when there is no current way to get around it (besides gutting that > > stuff from ebuild.sh). > > `scanelf -Xr` fixes insecure runpaths now > What is the correct command for scanelf -Xr ? What Args should you use? scanelf -Xr /PATH/TO/EXECUTABLE I just tried the scanelf -Xr, and it doesn't work (it only prints and assumes the RPATH is correct).
I don't like chrpath -d "${x}" in this situation -- it removes the RPATH, which may have validity besides the fact that it has ${BUILDDIR} in it, and maybe some null directories. Instead, try this (line 1043 of my current Portage install):
if type -p scanelf > /dev/null ; then
# Make sure we disallow insecure RUNPATH/RPATH's
# Don't want paths that point to the tree where the package was built
# (older, broken libtools would do this). Also check for null paths
# because the loader will search $PWD when it finds null paths.
f=$(scanelf -qyRF '%r %p' "${D}" | grep -E "(${BUILDDIR}|: |::|^ )")
if [[ -n ${f} ]] ; then
echo -ne '\a\n'
echo "QA Notice: the following files contain insecure RUNPATH's"
echo " Please file a bug about this at http://bugs.gentoo.org/"
echo " For more information on this issue, kindly review:"
echo " http://bugs.gentoo.org/81745"
echo "${f}"
echo -ne '\a\n'
# BEGIN TYGRIS PATCH
if hasq fixrpaths ${FEATURES} && type -p chrpath > /dev/null; then
# Try to intelegently fix these files.
# Unfortunately, scanelf is no use, and chrpath is the
# better tool for the job.
xrpath='';
for x in ${f}; do
if [ -f "${x}" ]; then
# Assume xrpath is assigned and done.
echo chrpath -r "${xrpath}" "${x}"
else
# Fix xrpath
xrpath=''
for y in ${x//:/ } ; do
if [ -n "${y}" -a "${y}" != "${BUILDDIR}" ] ; then
xrpath="${xrpath}:${y}"
fi
done
# Remove front colon
xrpath=${xrpath/#:/}
fi
done
fi
# die "Insecure binaries detected"
# END TYGRIS PATCH
fi
Give me a few to throughly test it out. I'll upload a proper patch if it works. Created attachment 81365 [details, diff]
ebuild.sh diff to fix insecure rpaths
Strangely enough, with the newest version of this patch, it seems to work but not properly error out or debug. Here's what I have. There's an "echo" for where chrpath is called (call be paranoid). If it works for folks here or can be adjusted, let me know. I can't seem to find where I messed up.
scanelf looks that the env variable TMPDIR as apart of it's checks TMPDIR=/var/tmp/portage/ scanelf -qXr /PATH/TO/EXECUTABLE The rpath behavior changes are handled in another bug. chrpath wont be used. This will be solved by the enhancement requested in bug 124962, closing this one as dupe. *** This bug has been marked as a duplicate of 124962 *** |
