[bug #42411] gdomap chroots to /tmp
Follow-up Comment #3, bug #42411 (project gnustep): The bug submitter suggests: 1) create an empty directory in /run (optionally via tmpfiles.d) 2) or ship one in /usr/share/gdomap/empty-directory-for-chroot (or so) in the package itself 3) Don't chroot? That is less broken than chroot into a world-writable location. I believe 1) is not portable while 2) is not acceptable as a general solution since it is distro-specific. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42411 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42411] gdomap chroots to /tmp
Follow-up Comment #4, bug #42411 (project gnustep): I agree about 1 and 2 not being options. I don't agree with (3) since if we don't chroot then we have to assume that the executable has access to the whole filesystem ... and a chroot to /tmp can't possibly be less secure than that. Perhaps though, we could add a command-line argument to specify the directory to which we should chroot, and only use the existing location if that argument is not provided? Then a distro could have a startup script which jails the process in a known-safe location for that distro. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42411 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42411] gdomap chroots to /tmp
Follow-up Comment #1, bug #42411 (project gnustep): I don't mind making things even more paranoid, but I don't know of an empty, non-writable directory that the program can reliably move to, and creating a directory which could then not be cleaned up on program termination (because the program is chrooted inside it) does not seem an acceptable option. Is there a standard portable way to do this (a quick internet search didn't reveal anything to me)? Failing that, is there a debian specific standard for this which could be conditionally compliled when building on a debian system? ___ Reply to this item at: http://savannah.gnu.org/bugs/?42411 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42411] gdomap chroots to /tmp
Follow-up Comment #2, bug #42411 (project gnustep): I don't know either, I'll ask the original bug submitter. is there a debian specific standard for this which could be conditionally compliled when building on a debian system? I don't think so. I believe this was not caught by an automatic security-check tool. It's just that some people have a habit to review daemons' code and gdomap seems to be getting a lot of attention :-) ___ Reply to this item at: http://savannah.gnu.org/bugs/?42411 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42411] gdomap chroots to /tmp
URL: http://savannah.gnu.org/bugs/?42411 Summary: gdomap chroots to /tmp Project: GNUstep Submitted by: yavor Submitted on: Fri 23 May 2014 07:54:06 PM EEST Category: Base/Foundation Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: Another report from Debian, original URL: http://bugs.debian.org/741441 gdomap chroots to /tmp as another level of paranoia. However if you are paranoid, you really want to chroot to an empty, non-writable directory, not to a world-writable one containing random files. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42411 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
