| Summary: | sys-apps/portage-2.1.10.10: sandbox access violation triggered by /var/tmp/portage symlink | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Martin Mokrejš <mmokrejs> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | sandbox |
| Priority: | Normal | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 373933, 673738 | ||
|
Description
Martin Mokrejš
2011-08-08 21:02:42 UTC
Expected behavior: /var/tmp # /var/tmp # mv /mnt/external/var/tmp/portage . /var/tmp # emerge -uN gcc Calculating dependencies... done! >>> Verifying ebuild manifests >>> Starting parallel fetch >>> Emerging (1 of 3) sys-devel/gcc-4.5.3 * gcc-4.5.3.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * gcc-4.5.3-uclibc-patches-1.0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * gcc-4.5.3-patches-1.0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * gcc-4.5.3-piepatches-v0.4.5.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * gcc-4.4.3-specs-0.2.0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * ecj-4.5.jar RMD160 SHA1 SHA256 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking gcc-4.5.3.tar.bz2 to /var/tmp/portage/sys-devel/gcc-4.5.3/work >>> Unpacking gcc-4.5.3-patches-1.0.tar.bz2 to /var/tmp/portage/sys-devel/gcc-4.5.3/work >>> Unpacking gcc-4.5.3-uclibc-patches-1.0.tar.bz2 to /var/tmp/portage/sys-devel/gcc-4.5.3/work ^Z [1]+ Stopped emerge -uN gcc It's not a normal permission issue, it's really a sandbox violation, similar to bug 308933. Please post the output of the following commands: portageq envvar PORTAGE_TMPDIR readlink -f $(portageq envvar PORTAGE_TMPDIR) readlink -f $(portageq envvar PORTAGE_TMPDIR)/portage It seems like the problem is that ${PORTAGE_TMPDIR}/portage is a symlink. If you set PORTAGE_TMPDIR="/var/tmp/portage" in make.conf, then the code from bug 308933 should work as intended to follow the symlink. On the working setup: # portageq envvar PORTAGE_TMPDIR /var/tmp # readlink -f $(portageq envvar PORTAGE_TMPDIR) /var/tmp # readlink -f $(portageq envvar PORTAGE_TMPDIR)/portage /var/tmp/portage Now screwing up the system: # mv /var/tmp/portage /mnt/external/var/tmp # cd /var/tmp/ # ln -s /mnt/external/var/tmp/portage . # portageq envvar PORTAGE_TMPDIR /var/tmp # readlink -f $(portageq envvar PORTAGE_TMPDIR) /var/tmp # readlink -f $(portageq envvar PORTAGE_TMPDIR)/portage /mnt/external/var/tmp/portage # Indeed, the below works for me: # PORTAGE_TMPDIR="/var/tmp/portage" emerge -uN gcc I propose that few sanity checks are introduced in emerge/sandbox, wherever the code leaks. Back to the directory permissions, several times I had problem that I screwed perms on portage/ or its parent /var/tmp/. Be it the missing sticky or similar. Please print a useful error to the user. I believe emerge does stat() few times over all those dires so it is not that epensive to check the perms and require the intended privs. I remember the advices in bugzilla were "... open a live-dvd" and see what perms are there and fix them on you filesystem manually". That is not nice. We have a _check_temp_dir() function that would could extend to check for a ${PORTAGE_TMPDIR}/portage symlink and then bail out with a suggestion for an appropriate PORTAGE_TMPDIR setting.
I do not understand why I have to change anything as a user as long as I keep the directory tree structure. In my eyes introducing a symlink to be traversed should not break the system. It is perfectly legal to place some directory on a different device/filesystem and introduce a symlink to that place from the original location. I ma probably missing something ... (In reply to comment #5) > I do not understand why I have to change anything as a user as long as I keep > the directory tree structure. In my eyes introducing a symlink to be traversed > should not break the system. It's due to the implementation details of sys-apps/sandbox. It uses canonical paths, so that the sandbox won't be accidentally escaped via symlinks. > It is perfectly legal to place some directory on a different device/filesystem > and introduce a symlink to that place from the original location. I ma probably > missing something ... I'm not sure if it's feasible for sandbox to support symlinks like this. If it can, it would be a feature request for sys-apps/sandbox. Anyway, it's beyond the scope of sys-apps/portage unless sys-apps/sandbox provides a way to alter the way that it uses canonical paths, and I suspect that it does not at this time. (In reply to comment #4) > We have a _check_temp_dir() function that would could extend to check for a > ${PORTAGE_TMPDIR}/portage symlink and then bail out with a suggestion for an > appropriate PORTAGE_TMPDIR setting. This is implemented in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=8a85160f4833e3f02470961fc2e05ec93f466566 Why don't you use os.path.islink()? Actually, if I got you right why don't you traverse the whole path from '/' down to ${PORTAGE_TMPDIR}/portage and check that none of the nodes is a symlink (if they are not supported by sanbox)? And if so, an error should be raised.
Am a bit lazy now at 3AM here to check myself but does that mean one may place whole /var/tmp onto the different device/filesystem? And/or does that means that
FEATURES=-usersandbox emerge blah
or
FEATURES=-sandbox?
(did not get their difference from the too brief description in make.conf)
will obey the issue and /var/tmp/portage could be a symlink? Then include that note in the text message printed to the user in your patch, that will help people. ;) Thanks. :))
(In reply to comment #8) > Why don't you use os.path.islink()? I suppose that would work, but I'd prefer to implement it so that it matches the implementation of sandbox a close as possible. Since sandbox would do the equivalent of realpath(), that's what I used. > Actually, if I got you right why don't you > traverse the whole path from '/' down to ${PORTAGE_TMPDIR}/portage and check > that none of the nodes is a symlink (if they are not supported by sanbox)? And > if so, an error should be raised. Well, it's not a problem if any of the PORTAGE_TMPDIR parents is a symlink, because we already realpath that anyway: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b414c49cec13202c34ea4115f79978ca7177acaf > Am a bit lazy now at 3AM here to check myself but does that mean one may place > whole /var/tmp onto the different device/filesystem? The default PORTAGE_TMPDIR is /var/tmp, but you can use any directory you want. > And/or does that means > that > > FEATURES=-usersandbox emerge blah > or > FEATURES=-sandbox? > > (did not get their difference from the too brief description in make.conf) The error only applies to people who have sandbox enabled, so there's no point in triggering the error otherwise. > will obey the issue and /var/tmp/portage could be a symlink? Then include that > note in the text message printed to the user in your patch, that will help > people. ;) Thanks. :)) Generally, we advise people to have sandbox enabled. So, if it's enabled, it's better to suggest a solution that doesn't involve disabling sandbox. simply change your PORTAGE_TMPDIR. it's really not that hard. *** This bug has been marked as a duplicate of bug 80085 *** (In reply to comment #6) > (In reply to comment #5) > > I do not understand why I have to change anything as a user as long as I keep > > the directory tree structure. In my eyes introducing a symlink to be traversed > > should not break the system. > > It's due to the implementation details of sys-apps/sandbox. It uses canonical > paths, so that the sandbox won't be accidentally escaped via symlinks. > > > It is perfectly legal to place some directory on a different device/filesystem > > and introduce a symlink to that place from the original location. I am > > probably missing something ... > > I'm not sure if it's feasible for sandbox to support symlinks like this. If it > can, it would be a feature request for sys-apps/sandbox. Anyway, it's beyond > the scope of sys-apps/portage unless sys-apps/sandbox provides a way to alter > the way that it uses canonical paths, and I suspect that it does not at this > time. Thinking of it more I wouldn't move whole /var/tmp to a different location because the connection to the external USB-drive is shaky, some files are already opened after a boot up ... I see portage/sanbox expand the symlink to its target automagically if it is the very top node of the tree because this worked for me: PORTAGE_TMPDIR="/var/tmp/portage" while it was a symlink to /mnt/external/var/tmp/portage. Actually, I could have done also either of PORTAGE_TMPDIR="/mnt/external/var/tmp" or PORTAGE_TMPDIR="/mnt/external/var/tmp/portage", right? Yes, you can set PORTAGE_TMPDIR to anything you want. It's the portage directory underneath it that can't be a symlink. (In reply to comment #7) > (In reply to comment #4) > > We have a _check_temp_dir() function that would could extend to check for a > > ${PORTAGE_TMPDIR}/portage symlink and then bail out with a suggestion for an > > appropriate PORTAGE_TMPDIR setting. > > This is implemented in git: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=8a85160f4833e3f02470961fc2e05ec93f466566 This is in 2.1.10.11 and 2.2.0_alpha51. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=464a65b848eb1344cd1eff3545bed311c01d97ea commit 464a65b848eb1344cd1eff3545bed311c01d97ea Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-01-01 20:55:41 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-01-01 20:57:54 +0000 _check_temp_dir: fix message to refer to correct bug 378403 Bug: https://bugs.gentoo.org/378403 Fixes: 8a85160f4833 ("_check_temp_dir: check for 'portage' symlink") Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/package/ebuild/doebuild.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=be2312f4f9bf854897431440734a765f5279c7d1 commit be2312f4f9bf854897431440734a765f5279c7d1 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-01-02 23:40:57 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-01-03 08:24:40 +0000 ebuild.sh: sandbox write to ${PORTAGE_TMPDIR}/portage (bug 673738) In ebuild.sh, grant sandbox write access directly to ${PORTAGE_TMPDIR}/portage, since write access to ${PORTAGE_TMPDIR} itself is not needed. Also, remove the _check_temp_dir symlink check from bug 378403, since a symlink is permissible if write access is granted directly to ${PORTAGE_TMPDIR}/portage. Bug: https://bugs.gentoo.org/673738 Bug: https://bugs.gentoo.org/378403 Signed-off-by: Zac Medico <zmedico@gentoo.org> bin/ebuild.sh | 4 ++-- lib/portage/package/ebuild/doebuild.py | 27 ++------------------------- 2 files changed, 4 insertions(+), 27 deletions(-) |
