Certain gnustep-apps such as terminal and textedit cause sandbox violations because they want to add ssh keys to /root/.ssh/known_hosts (they also ask for user intervention during the emerge process which presumably shouldn't happen). gnustep-libs/prefsmodule also exhibits this. gnumail and gorm fetch cvs code as do many other gnustep ebuilds and do not suffer from either the sandbox violation or the interactivity problem. emerge 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 The authenticity of host 'savannah.gnu.org (199.232.41.3)' can't be established. RSA key fingerprint is 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5. Are you sure you want to continue connecting (yes/no)? yes ACCESS DENIED open_wr: /root/.ssh/known_hosts Failed to add the host to the list of known hosts (/root/.ssh/known_hosts). * 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-17673.log" open_wr: /root/.ssh/known_hosts --------------------------------------------------------------------------------
- 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.
