http://www.sandboxie.com/?StartCommandLine – it might need some communication trickery to get the output back. However, I’d slightly got the wrong end of the stick: I thought the aim was sandboxing the opam-repository test builds, rather than all client builds!
For ‘advanced’ tricks like LD_PRELOAD, OPAM needs to remember the MSVC (i.e. non-GNU) ports – I am reasonably certain that the Microsoft Linker has no equivalent to LD_PRELOAD. The general Windows mechanism is code/DLL injection (which is part of how Sandboxie works)… David From: [email protected] [mailto:[email protected]] On Behalf Of Roberto Di Cosmo Sent: 24 February 2015 07:37 To: David Allsopp Cc: [email protected]; Louis Gesbert Subject: Re: [opam-devel] OPAM 1.3 roadmap Thanks David, this seems quite a useful app for people on Windows, but I did not find out whether it can be used as a console command: the documentation seems to imply that one needs to run its GUI, which is not gonna work for Opam... Maybe also on Windows we should stick to LD_PRELOAD, but I never tried that in practice... I wonder whether it will work with the cygwin/mingw toolchain. 2015-02-23 10:09 GMT+01:00 David Allsopp <[email protected]<mailto:[email protected]>>: Roberto Di Cosmo wrote: > On Mon, Feb 23, 2015 at 10:07:58AM +0900, Louis Gesbert wrote: > > That's starting to sound fairly consistent: > > > > # Secure OPAM itself a bit: > > > > * Sandbox the build step: not sure how to do it, but it should be > without network access, and only allowed to write to its build dir. > > This is really *not easy* in the current state of affairs > > -> opam calls whatever command is declared in the build:/install: fields > > -> this command can do whatever it wants; a sloppy Makefile might very > well end > up removing all the user-writeable files on a machine; think of > something like > > PREFIX=$(HOME)/$(MYNICELOCALVAR) # ooops ... using a var defined > only on the dev machine! > > install: > rm -rf $(PREFIX) # clean up dest dir on the dev machine; rm -rf > $(HOME) everywhere else! > .... > -> it's easy to pass through the integration test on opam-repository too: > if > somebody really wants to make bad jokes, one can simply check the > environment to be nice when going through Travis, and wreak havoc > elsewhere > > In the GNU/Linux distribution world, we face a similar challenge, with > install scripts being on top run as root; the very stringent QA process > enforced by these communities mitigates the problem quite a bit, of > course, but it is still there and s*it happens. > > That's why I was asking for the characteristics of the sandboxing > techniques we known. As with security, "sandbox" is a term easy to use, > but difficult to achieve. > > My best bet is _really_ the ptrace approach followed by Mcqueen in > http://robot101.net/files/trace.tar.gz as it allows to monitor _all_ file > access even by statically linked binaries, and is able to make a backup > copy of modified files (to restore them, if something goes wrong). > > What I do not know is whether something similar is available for *BSD, and > even less for Windows. See http://www.sandboxie.com/ for Windows. David -- Roberto Di Cosmo ------------------------------------------------------------------ Professeur En delegation a l'INRIA PPS E-mail: [email protected]<mailto:[email protected]> Universite Paris Diderot WWW : http://www.dicosmo.org Case 7014 Tel : ++33-(0)1-57 27 92 20 5, Rue Thomas Mann F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo FRANCE. Twitter: http://twitter.com/rdicosmo ------------------------------------------------------------------ Attachments: MIME accepted, Word deprecated http://www.gnu.org/philosophy/no-word-attachments.html ------------------------------------------------------------------ Office location: Bureau 320 (3rd floor) Batiment Sophie Germain Avenue de France Metro Bibliotheque Francois Mitterrand, ligne 14/RER C ----------------------------------------------------------------- GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
_______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
