Albert Cahalan
2007-11-07 17:06:21 UTC
For ages now, Linux has supported the features required to do
fully private (very secure) /tmp and /var/tmp directories.
It's time to use these features.
First, create a new namespace. As root, do this:
clone(NULL,NULL,CLONE_NEWNS,NULL); // use it like fork()
Next, bind-mount something appropriate onto /tmp and /var/tmp.
Note that /var/tmp ought to survive reboot, so it goes in nand.
Subject to proper error handling and fixes for races and such,
approximate shell commands might be:
mkdir /var/tmp/12345
mount --bind /var/tmp/12345 /var/tmp
mkdir -l /tmp
mount -t tmpfs -o mode=777 tmpfs /tmp
mount --bind /some-empty-dir /something-to-hide
...where "12345" is the UID, perhaps allocated as the PID of
the current (root) process plus 10000.
That's one less portability problem. $(SUGAR_ACTIVITY_ROOT)/tmp
can just go away.
fully private (very secure) /tmp and /var/tmp directories.
It's time to use these features.
First, create a new namespace. As root, do this:
clone(NULL,NULL,CLONE_NEWNS,NULL); // use it like fork()
Next, bind-mount something appropriate onto /tmp and /var/tmp.
Note that /var/tmp ought to survive reboot, so it goes in nand.
Subject to proper error handling and fixes for races and such,
approximate shell commands might be:
mkdir /var/tmp/12345
mount --bind /var/tmp/12345 /var/tmp
mkdir -l /tmp
mount -t tmpfs -o mode=777 tmpfs /tmp
mount --bind /some-empty-dir /something-to-hide
...where "12345" is the UID, perhaps allocated as the PID of
the current (root) process plus 10000.
That's one less portability problem. $(SUGAR_ACTIVITY_ROOT)/tmp
can just go away.