Summary: | sandbox violations in various gnustep ebuilds | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Colin Macdonald <cbm> |
Component: | New packages | Assignee: | Gentoo Gnustep project <gnustep> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2004.3 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Patch for cvs.eclass to disable X11 forwarding
2nd patch for cvs.eclass |
Description
Colin Macdonald
2004-12-05 13:57:37 UTC
- Add 'userpriv' and 'usersandbox' to your FEATURES in /etc/make.conf (i personally suggest never turning them off unless you absolutely have to) - remove temp files: 'rm -Rf /var/tmp/portage/* - make sure permissions are correct: 'chown -R portage:portage /usr/portage/distfiles/cvs-src' - try to emerge again This bug is impossible to fix, currently, for cvs-based ebuilds -- but since cvs-based ebuilds will never leave ~ARCH, this sadly has to be acceptable, for the meanwhile. This bug is known about, and unfixable w/o addwrites, or an imaginary "RESTRICT='userpriv'" (but there is a RESTRICT='nouserpriv', funny enough) Yes that did the trick. Except that I have to set "ForwardX11" to no in my /etc/ssh/ssh_config to prevent the following: emerge -v gnustep-apps/terminal Calculating dependencies ...done! >>> emerge (1 of 1) gnustep-apps/terminal-0.9.5_pre20041116 to / >>> Unpacking source... * Fetching CVS module System into /usr/portage/distfiles/cvs-src/savannah.gnu.org-backbone ... * Running cvs -q -d "anoncvs@savannah.gnu.org:/cvsroot/backbone" update -dP -D 20041116 System Warning: No xauth data; using fake authentication data for X11 forwarding. * Copying System from /usr/portage/distfiles/cvs-src/savannah.gnu.org-backbone ... * CVS module System is now in /var/tmp/portage/terminal-0.9.5_pre20041116/work >>> Source unpacked. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-gnustep-apps_-_terminal-0.9.5_pre20041116-10894.log" open_wr: /root/.xauth3MjrGi-c open_wr: /root/.xauth3MjrGi-c open_wr: /root/.xauth3MjrGi-c open_wr: /root/.xauth3MjrGi-c open_wr: /root/.xauth3MjrGi-c open_wr: /root/.xauth3MjrGi-c open_wr: /root/.xauth3MjrGi-c open_wr: /root/.xauth3MjrGi-c open_wr: /root/.xauth3MjrGi-c open_wr: /root/.xauth3MjrGi-c -------------------------------------------------------------------------------- Is cvs-src stuff generic enough that I should file a bug about this? The fix should be simple enough to add ssh -X or something when portage tries to use cvs. Ahh...that is a slightly different error that I've seen once before, that I likely can fix. I'll reopen the bug and work on this aspect of it. Created attachment 45346 [details, diff]
Patch for cvs.eclass to disable X11 forwarding
What to do:
# cd /usr/portage/eclass
# cp cvs.eclass /tmp
# patch < /path/to/cvs.eclass-x11-forward-no.patch
# rm -Rf /var/tmp/portage/*
# emerge -pv gnustep-apps/terminal
# emerge gnustep-apps/terminal
- Report here if it works
- If it does, you can leave it in; your next emerge --sync will update the
cvs.eclass anyway, if not:
# cp /tmp/cvs.eclass ./cvs.eclass
It didn't help. No change from the output above. Strangely, I inserted some einfo and ewarn commands near your patch and they never showed up. Does portage cache these eclasses? I tried emerge metadata and that didn't help... Okay, I chose 3 different cvs style ebuilds (different in how they pull cvs), and I'd like to see if all of them fail, some or one in particular. Try: ext style: `emerge gnustep-apps/gwnet` "no" style: `emerge gnustep-apps/terminal` (likely this will fail again) pserver style: `emerge gnustep-apps/preview` Thanks again. Once I/we narrow down which ones trigger the response, I think I will have a good idea how to fix it. Created attachment 45356 [details, diff]
2nd patch for cvs.eclass
Please try this one now, same methods, and let me know if it works.
I would be quite happy to finally squash this bug, as it seems to affect some,
but not all people.
Using the original cvs.eclass: emerge gnustep-apps/gwnet fails emerge gnustep-apps/terminal fails emerge gnustep-apps/preview works using the cvs.eclass patched with cvs.eclass-x11-forward-no.patch2: emerge gnustep-apps/gwnet works emerge gnustep-apps/terminal works emerge gnustep-apps/preview works Looks like you got it to me! I just realized that this is probably a duplicated of bug #70967. I'm guessing in that bug, the cause was "ForwardX11 yes" in /etc/ssh/ssh_config too. Safe enough to close this I think. |