On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
It can be specified as 1 or whatever. I just planned on a true value.
Well, for the filename operation it should be protected by the file object protection anyway, but ignoring this fact, I get your point.
My worry with this is that by providing checking functions that just return true or false that people will rely on those too much and have logic errors in their check and let security holes develop. That is why the checking functions as they stand now are macros that do the error return for you.
If people *really* need this I can add check functions and rename the current check functions to be more like "require" functions. I just want to hear other people say they will need this that often to warrant the risk of supporting possible security leaks from coding mistakes.
-Brett
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > (2) For the APIs returning an int, it wasn't clear what that int
> > would be, other than NULL => interpreter is trusted.
> Doesn't matter. I should probably change it to a say "a false value"
> instead of NULL.
But what if they succeed? Do they return -1, 1, the amount allocated, ...
It can be specified as 1 or whatever. I just planned on a true value.
> > (3) Should PyXXX_Trusted have a variant that takes group/type/string,
> > meaning "Am I allowed to do *this*?", rather than having to
> > special-case the "You can do anything" case?
> The PyXXX_Trusted() case is meant as a blanket trusted/untrusted test. If
> you want more fine-grained, use the other checking functions (e.g.,
> PyXXX_ExtendedCheckValue(), etc.).
You gave an example of a library that was generally useful even in
restricted mode, but had one convenience function that shouldn't
always be permitted.
I imagine a function that is dangerous only because it takes a
filename rather than an open stream; I want to wrap it in some sort of
guard, but I would rather make a single "Can I do this?" query.
Well, for the filename operation it should be protected by the file object protection anyway, but ignoring this fact, I get your point.
Under the current API, I would need separate logic for "The
interpreter is completely trusted" and "The interpreter is not
trusted, but can do _this_". In practice, I'm betting that many
extension modules will skip at least one of these steps.
My worry with this is that by providing checking functions that just return true or false that people will rely on those too much and have logic errors in their check and let security holes develop. That is why the checking functions as they stand now are macros that do the error return for you.
If people *really* need this I can add check functions and rename the current check functions to be more like "require" functions. I just want to hear other people say they will need this that often to warrant the risk of supporting possible security leaks from coding mistakes.
-Brett
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
