Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 641022
Summary: | python-debuginfo package owns a world-writable /usr/src/debug/tmp directory | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Fabrice Bellet <fabrice> |
Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 25 | CC: | dmalcolm, fedora, ignatenko, ivazqueznet, james.antill, jonathansteffan, kardos.lubos, mclasen, mjw, packaging-team-maint, robinlee.sysu, vmukhame |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | rpm-4.13.0.1-4.fc26 rpm-4.13.0.1-2.fc25 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-09-03 04:23:30 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 468246 |
Description
Fabrice Bellet
2010-10-07 15:02:17 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping persist in python-debuginfo-2.7.5-11.fc20.x86_64 This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Persist in python-2.7.10-1.fc23 This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23 This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Hmm, the package owning /usr/src/debug/tmp changed to glib2-debuginfo in Fedora 24. Reassigning. [root@bonobo ~]# rpm -qf /usr/src/debug/tmp glib2-debuginfo-2.48.2-1.fc24.x86_64 [root@bonobo ~]# ls -ld /usr/src/debug/tmp drwxrwxrwt. 2 root root 4096 Aug 18 07:42 /usr/src/debug/tmp [root@bonobo ~]# rpm -V glib2-debuginfo-2.48.2-1.fc24.x86_64 [root@bonobo ~]# In case that binary compiled from source generated in /tmp, a /usr/src/debug/tmp directory will be created with the same mode as /tmp, a.k.a 777, which should be avoided. Upstream PR: https://github.com/rpm-software-management/rpm/pull/194 (In reply to Robin Lee from comment #8) > In case that binary compiled from source generated in /tmp, a > /usr/src/debug/tmp directory will be created with the same mode as > /tmp, a.k.a 777, which should be avoided. > > Upstream PR: https://github.com/rpm-software-management/rpm/pull/194 Thanks. Explicitly setting all directories under /usr/debug/src to 0755 instead of using a+rx is a very good idea. It is surprising we didn't catch this earlier. Besides that fix (which I agree should be included) we should figure out why the (empty) tmp dir is included in the fist place directly under /usr/src/debug/. We are doing something else wrong if we include any file or directory not under /usr/src/debug/<package-nvr>/. I suspect there is some relative path (../../tmp/.. ?) involved that somehow confuses debugedit or find-debuginfo.sh. So please keep this bug open even if the above patch is applied. (In reply to Mark Wielaard from comment #9) > (In reply to Robin Lee from comment #8) > > In case that binary compiled from source generated in /tmp, a > > /usr/src/debug/tmp directory will be created with the same mode as > > /tmp, a.k.a 777, which should be avoided. > > > > Upstream PR: https://github.com/rpm-software-management/rpm/pull/194 > > Thanks. Explicitly setting all directories under /usr/debug/src to 0755 > instead of using a+rx is a very good idea. It is surprising we didn't catch > this earlier. > > Besides that fix (which I agree should be included) we should figure out why > the (empty) tmp dir is included in the fist place directly under > /usr/src/debug/. We are doing something else wrong if we include any file or > directory not under /usr/src/debug/<package-nvr>/. I suspect there is some > relative path (../../tmp/.. ?) involved that somehow confuses debugedit or > find-debuginfo.sh. So please keep this bug open even if the above patch is > applied. In the case of glib2, libgobject-2.0.so actually has a source file named /tmp/tmpXXXX.c. So it seems proper for debugedit to generate a path /tmp/tmpXXXX.c to $SOURCEFILE. Though /tmp/tmpXXXX.c is cleaned at the moment of debuginfo generating. A simple fix may be just travelling /usr/debug/src, and delete empty directories, in find-debuginfo.sh. After that, the most proper fix would be for all those packages that compiling binaries from temporary source files, generate the temporary source files within the build directory, and don't clean them after building. (In reply to Robin Lee from comment #10) > In the case of glib2, libgobject-2.0.so actually has a source file named > /tmp/tmpXXXX.c. So it seems proper for debugedit to generate a path > /tmp/tmpXXXX.c to $SOURCEFILE. Though /tmp/tmpXXXX.c is cleaned at the > moment of debuginfo generating. Aha. That does make sense. But it means you cannot really debug such code because we fail to ship that (generated) source file. > A simple fix may be just travelling /usr/debug/src, and delete empty > directories, in find-debuginfo.sh. We keep the empty directories in case there is a relative path through such a directory because some DWARF consumers rely on actual fill path to a source file existing. See this comment in debugedit.c: /* Ensure the CU current directory will exist even if only empty. Source filenames possibly located in its parent directories refer relatively to it and the debugger (GDB) cannot safely optimize out the missing CU current dir subdirectories. */ > After that, the most proper fix would be for all those packages that > compiling binaries from temporary source files, generate the temporary > source files within the build directory, and don't clean them after building. We used to have problems rewriting source path that would result in a larger path. But most of such issues have been resolved these days. So we could in theory include the actual source file and rewrite /tmp/foobar.c to /usr/debug/src/<package-nvr>/tmp/foobar.c. We just have to figure out when such files/paths make sense. I assume we don't want to do this for any standard include file under /usr/include/ for example. This can happen in two ways. Either a compile_unit has a comp_dir with a directory outside the RPM_BUILD_DIR or the compile_unit doesn't have a comp_dir, but the name attribute is an absolute path outside the RPM_BUILD_DIR. The following hello.spec shows the issue (using /var/tmp instead of /tmp/ to show this issue isn't unique to packages building some sources in /tmp). $ cat hello.spec Summary: hello world Name: hello Version: 1.0 Release: 1 License: GPL %description hello world %prep %setup -c -T %build echo 'int main (int argc, char **argv) { return 0; }' > /var/tmp/foo.c cp /var/tmp/foo.c /var/tmp/bar.c # This will change the comp_dir to /var/tmp. pushd /var/tmp gcc -g -o foo foo.c popd mv /var/tmp/foo foo # As long as say.c doesn't include any files no comp_dir will be created. # But the DW_AT_name will be the full file path. debugedit will use the # dirname as comp_dir. gcc -g -o bar /var/tmp/bar.c %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr/local/bin cp foo bar $RPM_BUILD_ROOT/usr/local/bin/ %files %defattr(-,root,root) /usr/local/bin/foo /usr/local/bin/bar %changelog * Thu Apr 20 2017 Mark Wielaard <mjw> - 1.0.1 - Hello $ rpmbuild -ba hello.spec $ rpm2cpio /home/mark/rpmbuild/RPMS/x86_64/hello-debuginfo-1.0-1.x86_64.rpm | cpio --list --verbose | grep var 63 blocks drwxr-xr-x 3 root root 0 Apr 21 11:52 ./usr/src/debug/var drwxrwxrwt 2 root root 0 Apr 21 11:52 ./usr/src/debug/var/tmp On fedora rawhide (with %_unique_debug_srcs set) the var and var/tmp directories end up under ./usr/src/debug/hello-1.0-1.x86_64/ which is slightly better (because then they won't conflict with other debuginfo packages). But still bogus since those locations are still empty and might actually be confused for actual directories with the same name that did exist under the original build root. With current trunk git rpm the directories are at least all chmod 0755. We really shouldn't include these directories (and if we do then we should also get the source files included). The cause is the code that makes sure that even if a directory (comp_dir) is empty we still include it (in case a file uses a relative path through it) is too greedy. It should only do that for directories which are actually under the original RPM_BUILD_DIR. (In reply to Mark Wielaard from comment #12) > We really shouldn't include these directories (and if we do then we should > also get the source files included). The cause is the code that makes sure > that even if a directory (comp_dir) is empty we still include it (in case a > file uses a relative path through it) is too greedy. It should only do that > for directories which are actually under the original RPM_BUILD_DIR. The following patch submitted upstream fixes that: http://lists.rpm.org/pipermail/rpm-maint/2017-April/005462.html If it gets accepted I'll add it and the patch from Robin Lee to explicitly set the directory mode to 0755 to the fedora rpm package. (In reply to Mark Wielaard from comment #13) > If it gets accepted I'll add it and the patch from Robin Lee to explicitly > set the directory mode to 0755 to the fedora rpm package. Accepted upstream and now in rpm-4.13.0.1-4.fc26 and rpm-4.13.0.1-20.fc27. rpm-4.13.0.1-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b8a3febd40 rpm-4.13.0.1-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b8a3febd40 rpm-4.13.0.1-4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. rpm-4.13.0.1-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-e9a1ddb533 rpm-4.13.0.1-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e9a1ddb533 rpm-4.13.0.1-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. |