[sugar] secure /tmp and /var/tmp

[Michael Stone]

On Wed, Nov 07, 2007 at 12:06:21PM -0500, Albert Cahalan wrote:

Albert,

Thanks very much for your suggestions.

In fact, as you can observe in the call to CreateActivity() in rainbow's
service.py, we already install each activity we create in a new
namespace.

> Next, bind-mount something appropriate onto /tmp and /var/tmp.

I talked about this with Ivan who requested, at the time, that we
continue using the $SAR directories instead of the FHS ones.

The basic idea was that we actually _do not_ want activities scribbling
all over the filesystem. Period. Certainly we could use the standard
paths, as you suggest. However, it was an intentional design decision to
break compatibility with the FHS.

> ...where "12345" is the UID, perhaps allocated as the PID of
> the current (root) process plus 10000.

I wish it were as easy as just setting the pid to something high, but
unforunately, Sugar gets cranky when /etc/passwd and /etc/group don't
contain accurate information about the pid and and primary gid of the
program that's running.

This is quite annoying to me because /etc/passwd and /etc/group seem
difficult to modify in an atomic fashion relative to actors using a
different reservation/locking discipline.

> That's one less portability problem. $(SUGAR_ACTIVITY_ROOT)/tmp
> can just go away.

Do you have some examples of programs which don't listen to $TMPDIR and
which don't take explicit paths to non-volatile storage? If so, would it
not be more appropriate to make these programs even more portable by
removing assumptions they're making about the environment in which
they're running?

[I've considered setting $HOME to point to one of $SAR/instancec or
$SAR/data, but the reason for separating them is that they have
different semantics and $HOME normally fits both roles]

Michael