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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
