[sugar] secure /tmp and /var/tmp
C. Scott Ananian
cscott at cscott.net
Thu Nov 8 12:27:24 EST 2007
On 11/8/07, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On Nov 8, 2007, at 18:09 , Marco Pesenti Gritti wrote:
> > Though applications backwards compatibility just doesn't make sense in
> > this context. We consciously broke it with the high level design, both
> > of the user experience and of the security framework.
>
> That's not the point. The point is how hard we make it for people to
> port their apps to Sugar. And in my opinion we should not make it
> unnecessarily hard.
I side with Ivan and Michael here -- it's a lot better to have an
immediate obvious failure when you try to write to /tmp than to have
mysterious failures when /tmp doesn't behave "as you expect".
Everyone sane should be using $TMPDIR anyway (either explicitly or via
mktemp and friends), and I could support setting $TMPDIR to
$SUGAR_LONG_STRING/tmp, but our last attempt at activity isolation did
all the magic to try to make things look 'normal' for activities, and
we ended up deciding that it was all much too confusing for normal
people. Normal programmers expect that what they see as /tmp is the
same as what everyone else sees as /tmp. I believe that we should
keep it this way. I have been convinced that file system namespace
magic should be reserved for instances where it is absolutely
completely required -- and I'm not convinced this is one of those
situations.
+1 to shortening the name of the $SAR env var, though -- although in
practice this should be probably accomplished by the user with
something like:
from sugar.variables import SUGAR_ACTIVITY_ROOT as SAR
--scott
--
( http://cscott.net/ )
More information about the Sugar
mailing list