While this looks like a nice idea on paper, I would not recommend to use the current implementation of 'maybe' on a system that hosts valuable data.<p>The tool seems to work by intercepting individual "blacklisted" system calls and then - instead of executing them - returning a nonsense value.<p>The issue is that this breaks every single POSIX spec and will therefore break any program that does more than a few trivial IO operations and relies on those operations to behave as specified.<p>So it might work for a simple demo case where a small script only does a single file modification and never checks the results, but for any serious program (think a database, a complex on-disk format or really anything that does network IO) this will lead to corruption and undefined behaviour as system calls will return erroneous success values or invalid file descriptors.<p>I think to actually make this work one would have to emulate the system calls and make sure everything stays POSIX compliant. Doing this correctly for calls like mmap might get tricky though (and won't be possible from within a python runtime). And even then it isn't obvious how something like network IO would be handled.
This would be more useful if it used a virtual file system.<p>What happens if the program writes a bunch of stuff to disk then later on tries to read it?
On Windows you have sandboxie (<a href="http://www.sandboxie.com" rel="nofollow">http://www.sandboxie.com</a>), a complete sandbox for your programs.
Nice idea. Shameless plug: this reminds me a ptrace hack I did a couple years back:<p>fluxcapacitor<p><a href="https://github.com/majek/fluxcapacitor#fluxcapacitor" rel="nofollow">https://github.com/majek/fluxcapacitor#fluxcapacitor</a><p><a href="https://idea.popcount.org/2013-07-19-how-to-sleep-a-million-years/" rel="nofollow">https://idea.popcount.org/2013-07-19-how-to-sleep-a-million-...</a>
Mbox does something similar, but seems to be more robust/complete: <a href="https://pdos.csail.mit.edu/archive/mbox/" rel="nofollow">https://pdos.csail.mit.edu/archive/mbox/</a>
It doesn't work this way, but my first expectation was that this would take an LVM2/ZFS snapshot and diff the file trees afterward. Then it'd be easily ported to Windows (VSS) and wouldn't have the subprocess issues on *BSD, but, the diff would be slower, unordered, and contain changes made by unrelated processes.
Also check out mbox:<p><a href="https://pdos.csail.mit.edu/archive/mbox/" rel="nofollow">https://pdos.csail.mit.edu/archive/mbox/</a><p>It's a bit more complete than this.
Ideally, you want ad hoc sandbox (like Sandboxie on Win32)<p>Ideally, Docker could offer ad hoc commands to launch an process in a sandbox. And then you launch a file explorer process in the same sandbox (like Sandboxie) to inspect or run a diff-tool that outputs statistics like the tool in the headline.
I would have used something like this when I was first learning rsync...<p>Even though I had read all of the man pages and knew the commands inside and out, it still seemed incredibly risky and scary to me to run rsync with the --delete function when I was backing up my main USB drive for the very first time.<p>Basically my biggest fear was that I had source and destination mixed up, which I didn't, but it would have been nice to run a test trial of that command before doing so.
Instead of a control approach: having to confirm every little action in there, It would be nicer to have a undo-able behavior: I actually run the script on the first time, but I can easily undo it if it did not work as expected.
The current state of the art is of no use for me.
I use Docker to achieve a similar thing...<p>1) Boot up a new Ubuntu docker container
2) Run command / script
3) Use `docker diff` to see what changes to the filesystem were made<p>Obviously it's only useful for some commands, but at least it's safe :-)
This seems neat, but from a security standpoint I'd much rather see a command which spawned a new VM with a copy of my current file-system.<p>I would then want to capture all disk and network i/o that the "maybed" command generated in the VM.<p>Even that wouldn't be that secure, because the command would still be able to send sensitive data out. You could intercept the network i/o, but that would cause most installers to fail.
Limited scope... this is local.<p>I use to implement a --trial in my shell scripts, which covers reporting of ALL operations (local and remote).<p>Anyway, this is a nice discover and nice hack.
Suggestion: Add a way to distinguish between parameters sent to maybe and parameters sent to the program. You don't accept any parameters at the moment, but you may want to in the future, and when you start wanting to do that, you may not want to break any existing usages by changing behavior. For that reason I think it would be good to introduce disambiguation now.
Sadly, it is not possible to combine this tool with programs that use ptrace themselves, because of limitations in the implementation of ptrace.<p>In Linux, a program that is being ptraced is not allowed to ptrace another program.
A really cool idea. Is this more or less how rootkits work and hide themselves? A system call is made to list the contents of a directory, and the rootkit excludes itself from that listing?
I feel like this would only be useful for badly written software.<p>Anything reliable would check that its operations went through as expected and bail really early.