Summary: | unlink under /dev fails with sandbox-1.2 | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Robin Johnson <robbat2> |
Component: | Sandbox | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | azarah |
Priority: | High | ||
Version: | 2.0 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 88589 | ||
Bug Blocks: | |||
Attachments: | sandbox-1.2.1-dev-usage.patch |
Description
Robin Johnson
2005-04-27 02:20:34 UTC
some permissions data: x29 ~ # ls -l /dev/shm/ # $PORTAGE_TMPDIR total 0 drwxrwxr-x 5 portage portage 100 Apr 27 02:19 portage drwxrwxr-x 2 portage portage 40 Apr 27 02:19 portage-pkg It breaks here regardless of userpriv in FEATURES if PORTAGE_TMPDIR="/dev/shm". Tried with /var/tmp on tmpfs and had no issues and my /dev/shm has default mount options so it must be something specifically to do with that directory. Related is bug #88589. Same problem here... OK, may I have a suggestion? echo ">=sys-apps/portage-2.0.50.20" >> /usr/portage/profiles/package.mask Seriously - 2.0.50.20-r* is not unstable, it is strictly experimental. No. Portage is very far from badly broken. In fact there are no regressions whatsoever in portage at all now. What you are talking about is the split out (and new version of) sandbox. However, other than the initial amd64 one, all the bugs received so far have been on broken systems or systems with not-the-norm configurations. Furthermore, this release has seen much fewer bugs than a regular "stable" release of portage has since I've been been on the team. ok, well then please repair the sandbox to the same level of functionality that it was in as of 2.0.51.19! PORTAGE_TMPDIR is basically the only major way I diverge from the default configuration, and it's only on tmpfs as I have lots of memory, so provides a big speed improvement. OK. I lost all my customized configs on a test box due to Bug 90148 and have had serious issues with sandbox with all subsequent versions. I call this "badly broken" for sure and I really think this should be package.masked. File a metabug about p.masking it (which frankly is stupid, since the bugs are already shaken out for the most part). Keep on topic on this bug... SANDBOX_DEBUG="1" SANDBOX_DEBUG_LOG="/tmp/debug-sandbox" PORTAGE_DEBUG="hooha" emerge whatever-triggers-it , and attach the logs to this bug. exact sys-apps/sandbox version you're triggering it with would be useful also. How about not having PORTAGE_TMPDIR in /dev/ ? Does that fix it (works over here with standard dir)? sandbox is sys-apps/sandbox-1.2.1-r2 Perhaps sandbox is a candidate for profiles/info_pkgs? ferringb: I ran: SANDBOX_DEBUG="1" SANDBOX_DEBUG_LOG="/tmp/debug-sandbox" PORTAGE_DEBUG="hooha" emerge portage and the debugging logfile wasn't even written. In fact the entire output is identical to the 'emerge portage' output I already posted here. Sandbox works perfectly with any path outside of /dev/shm. But as a test, I mounted some real disk to /dev/shm instead of using tmpfs, and found that also fails (again, identical errors to before). So it's something in how sandbox treats that path. describing a package as 'horribly broken' when using a non-standard/uncommon setup is incorrect /* XXX: Hack to make sure sandboxed process cannot remove * a device node, bug #79836. */ if (0 == strncmp(canonic, "/dev/", 5)) { errno = EACCES; return result; } jstubbs: Commenting that out makes it work :-). I think that logic there should be changed to deny unlink in all parts of /dev that AREN't otherwise allowed. jstubbs put together an initial patch for this. It works (emerge portage) now, but there is some extra output that is spewed. ... Compiling /dev/shm/portage/portage-2.0.51.20-r5/work/portage-2.0.51.20/pym/portage_file.py ... Compiling /dev/shm/portage/portage-2.0.51.20-r5/work/portage-2.0.51.20/pym/portage_gpg.py ... Compiling /dev/shm/portage/portage-2.0.51.20-r5/work/portage-2.0.51.20/pym/portage_localization.py ... Compiling /dev/shm/portage/portage-2.0.51.20-r5/work/portage-2.0.51.20/pym/portage_locks.py ... Compiling /dev/shm/portage/portage-2.0.51.20-r5/work/portage-2.0.51.20/pym/portage_util.py ... Compiling /dev/shm/portage/portage-2.0.51.20-r5/work/portage-2.0.51.20/pym/xpak.py ... >>> Test phase [not enabled]: sys-apps/portage-2.0.51.20-r5 /usr/lib/portage/bin/ebuild.sh: line 16: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 44: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 56: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 1362: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 1362: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 1362: /dev/null: Permission denied >>> Install portage-2.0.51.20-r5 into /dev/shm/portage/portage-2.0.51.20-r5/image/ category sys-apps man: /usr/lib/portage/bin/prepman: line 46: /dev/null: Permission denied /usr/lib/portage/bin/prepall: line 39: /dev/null: Permission denied >>> Completed installing portage-2.0.51.20-r5 into /dev/shm/portage/portage-2.0.51.20-r5/image/ /usr/lib/portage/bin/ebuild.sh: line 16: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 44: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 56: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 1362: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 1362: /dev/null: Permission denied /usr/lib/portage/bin/ebuild.sh: line 1362: /dev/null: Permission denied ./ ./usr/ ./usr/sbin/ ./usr/sbin/emerge-webrsync ./usr/sbin/regenworld ... Created attachment 57461 [details, diff]
sandbox-1.2.1-dev-usage.patch
Removes the hack for #79836 and moves /dev/null out of WRITE and into PREDICT.
i think /dev/zero should be moved too ? (not because we've had problems but because it's the right thing ?) No good. Moving /dev/null to SANDBOX_PREDICT doesn't allow the writes. The only difference between SANDBOX_PREDICT and SANDBOX_DENY is that SANDBOX_PREDICT failures are not logged and thus don't cause emerge to fail the package. I wasn't aware of this until testing out the patch... As a short term fix, it'll be easiest to just remove the hack for the dodgy toolchain versions and add a block against them. Long term will probably require a new class of access control. I still think its just plain silly to have PORTAGE_TMPDIR under /dev, and really do not go with why /dev/shm/ exists ... but that is just me. Blocker: Blocks development and/or testing work This bug has a very easy workaround. Fixed in sandbox-1.2.2. |