IDMS: Second thoughts about sandboxing

[Ambarisha B]

Hi,

As we discussed, I was planning to sandbox the worker. For this I
modified the libfetch to accept a connection.  After feeling uneasy
for a while, now I am convinced that I am doing it all wrong.

I don't think we should sandbox the worker. All the sandboxing,
capsicum integration etc. should be done within libfetch. My arguments
for this:

There are multiple independent (http/ftp) requests happening in each
worker. As such, it is both tedious and pointless to create all those
connections before hand, then sandbox and then use the connections.

I realized libfetch abstracted out creating a connection for a reason.
If we make a connection and sandbox, we won't be able to handle
redirects as we'll have to create a connection with the new target
site. If we handle redirects before sandboxing, we're basically doing
all the header processing before sandboxing anyway. Just the data
transfer would be sandboxed, which seemed pointless to me as it is
pretty straightforward.

Modifying libfetch to accept a connection, itself, was a hack. I had
three options. Sneak in the connection object in the url struct  or
change all the function prototypes or double all the functions with an
additional connection object parameter. I chose the first.

I think all the sandboxing should be done within libfetch because that
is the point where we can confidently say "I don't need to create any
more connections now". Ofcourse, this means more work with libfetch
and that some of the work I did is useless or has to be undone. But I
think its better to fix it now than later. I think, the best way to go
is to just assume libfetch is foolproof now and then make it foolproof
later by integrating it with capsicum. After spending some time on
this, I'm interested in trying it out myself.

I would love to be proven wrong here. That'll save a lot of work :)

Cheers
Ambarish