> File access is part of builtins, you can remove that.
> Even if you try, there's a million of sneaky ways to get it back, like the
> following:
>
> [t for t in type(1).__class__.__base__.__subclasses__() if hasattr(t,
> "write")][0]("/path/to/file", "w").write("my payload")
There're ways around any security measure; even UBISoft's "uncrackable" DRM for
their games was cracked this weekend.
> os and sys are not required for file access.
Bad example, but I hope the point was still made.
> Moreover, depending on the platform, they can be built into the interpreter
> (not external modules).
Aren't all 2.5 versions using an internal Python3.1 distribution that BF
controls? If folks are serious about this, external python in official builds
can be disallowed and the internal Python stack can be nerfed.
> Good luck with that.
> Even with an import hook, it's possible to go around such a measure.
Sure, but again, people could get around most of the suggestions that have come
up in this thread. Trying to catch the broadest attempts at security breaches
is all anyone can really be tasked with. At some point someone is going to
find a way around the security, and there will be issues. It's unavoidable.
> Sometimes it's not malicious. It could just be a poorly written script that
> craps files all over your HD if not run in a certain way.
Which is a very good point, and adds validity to the notion of a central
"trusted scripts" repository. Having a trusted scripts / rigs place online
that new users are pointed towards (instead of long BlenderArtists threads)
would go much further to solving these issues than adding security layers to
the software and inconveniencing long-time power users IMO.
Then again, it needs someone to manage it.
~ C
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
