Preventing execution of a method

[Emanuele D'Arrigo]

Sorry if I'm a bit thick here...

can any of the esteemed participant in this noble newsgroup confirm
that is not possible to prevent a python module's code from executing
the methods of another module?

I.e. if I have a class with two methods, doSomethingSafe() and
doSomethingDangerous(), is there a way to prevent another module from
executing doSomethingDangerous() but allow the execution of
doSomethingSafe()?

My understanding is that in python this is not possible. Can you
confirm?

Manu

 

[alex23]

I.e. if I have a class with two methods, doSomethingSafe() and
doSomethingDangerous(), is there a way to prevent another module from
executing doSomethingDangerous() but allow the execution of
doSomethingSafe()?

My understanding is that in python this is not possible. Can you
confirm?

Your understanding is correct.

The Python convention is to prefix non-public methods/classes etc with
an underscore, as in _doSomethingDangerous(). This is meant to
indicate to anyone using your module that they shouldn't use this
function, at least not without having a good understanding of what it
does.

 

[rdmurray]

Your understanding is correct.

The Python convention is to prefix non-public methods/classes etc with
an underscore, as in _doSomethingDangerous(). This is meant to
indicate to anyone using your module that they shouldn't use this
function, at least not without having a good understanding of what it
does.

There is, however, also the possibility of prefixing the method name
with '__'. The invokes 'name mangling', which makes it more difficult
(though not impossible, the idea is to avoid accidents) for the method
to be called from outside the class.

http://www.python.org/doc/2.5.2/tut/node11.html#SECTION0011600000000000000000.

--RDM

 

[MRAB]

Your understanding is correct.

The Python convention is to prefix non-public methods/classes etc with
an underscore, as in _doSomethingDangerous(). This is meant to
indicate to anyone using your module that they shouldn't use this
function, at least not without having a good understanding of what it
does.
>

You could add a little bit of protection by always passing a certain
object into _doSomethingDangerous().

_guard = object()

def _doSomethingDangerous(g):
if g is not _guard:
raise Exception("Don't do that!")

That would at least stop accidental calls.

 

[alex23]

There is, however, also the possibility of prefixing the method name
with '__'.  The invokes 'name mangling', which makes it more difficult
(though not impossible, the idea is to avoid accidents) for the method
to be called from outside the class.

That only works for methods, it has no effect on functions or classes
within modules:

module.py:
def __f(): pass

class __F(object):
def __f(): pass
Traceback (most recent call last):
<bound method __F.__f of <module.__F object at 0x00B89B30>>

 

[alex23]

That only works for methods, it has no effect on functions or classes
within modules:

And of course -now- I realise that the OP was asking for protecting
methods. Please disregard my last post

 

[r]

And of course -now- I realise that the OP was asking for protecting

methods. Please disregard my last post

Alex23,
Are you telling me that you do not know how to YANK your own post? I
find that hard to believe.

 

[Emanuele D'Arrigo]

Thank you all for the confirmation and the suggestions (including the
tangential ones: I didn't know one could remove your his own posts!).

As much as I really like Python (which I've been using full-time only
for the past two months) I really wish it did have regular private/
protected/public methods.

I'm building an application that can be extended by the users and I
really wish there was a solid way to prevent them from accessing parts
of the application that they shouldn't access or to provide read-only
access. I.e. right now I'm working on the graphical client which
potentially could be rewritten entirely by the users. It is necessary
and perfectly reasonable for the client module to access some of the
objects to be represented graphically, but those objects shouldn't be
modifiable by it.

I now wonder, would developing the graphical client as an entirely
separate application, communicating with the server via the localhost
network interface and messages, solve the problem? Would it keep the
objects of the two applications (server/client) entirely separate?

Manu

 

[Bruno Desthuilliers]

Emanuele D'Arrigo a écrit :

Sorry if I'm a bit thick here...

can any of the esteemed participant in this noble newsgroup

Ain't that a bit over the border ?-)

confirm
that is not possible to prevent a python module's code from executing
the methods of another module?

I.e. if I have a class with two methods, doSomethingSafe() and
doSomethingDangerous(), is there a way to prevent another module from
executing doSomethingDangerous() but allow the execution of
doSomethingSafe()?

My understanding is that in python this is not possible. Can you
confirm?

Well... If you really want a totally secure, absolute protection of
doSomethingDangerors, the only way is to run client code on a distinct
machine (implied : you have a client/server protocol).

Now the question is : do you _really_ need this level of security ?

If you want to "protect" your implementation methods (and other
attributes FWIW) from python developpers - IOW, to warn them they
_should_ not use them -, just prepend the name with a single leading
underscore. Yes, this is just a convention, but it's a very strong one.

If you want to protect some critical attributes (methods or whatever)
from _accidental_ redefinitions, prepend the name with two underscores.
This will invoke a name mangling mechanism such that what's internally
known as __my_attribute or __my_method is only externally (child classes
or any other code) as _MyClass__my_attribute (resp. _MyClass__my_method).

The next step would require using a lexical closure - IOW, define
do_something_dangerous *and* all the methods needing access to it in a
same function, and make this function return only "safe" functions, ie:

class MyClass(object):
def private_stuff_inside():
def do_something_dangerous(self, whatever):
# code here
def do_something_safe(self, yadda):
# code here
# NB : note the explicit passing of self here
foo = do_something_dangerous(self, yadda)
# more code here
def do_another_safe_thing(self, yadda):
# code here
bar = do_something_dangerous(self, yadda)
# more code here
return do_something_safe, do_another_safe_thing

do_something_safe, do_another_safe_thing = private_stuff_inside()
del private_stuff_inside()


This is not 100% safe, but accessing do_something_dangerous requires
some work, pretty good Python knowledge (and either access to the source
code or 'luck' or being very nasty, since there's no simple way to even
know do_something_dangerous exists). As far as I'm concerned, I'd say
that it's as safe as a Java so-called "private" method (which can always
be accessed thru reflexion FWIW...).

If that's still not enough, then *no* existing language will have
sufficiant protection (hint : how hard is it to get a crack for
Photoshop ?), and you're back to not even distributing the critical part
of your code - IOW, have the critical part only live on your own server.

A last word: unless do_something_dangerous *really* do something
"dangerous"[1] or business-critical[2] - in which cases you just don't
want to let _anyone_ access your code, not even in byte-compiled form -,
the two first solutions are good enough. FWIW and as far as I'm
concerned, I wouldn't even bother using the second one (name mangling)
unless I really have a pretty good reason to do so.


[1] like controlling a nuclear powerplant, posting all your porns to all
your addressbook, or such...

[2] IOW : it's your very secret killing algorithm that none of your
concurrents must learn or your out of business

 

[Bruno Desthuilliers]

Emanuele D'Arrigo a écrit :

Thank you all for the confirmation and the suggestions (including the
tangential ones: I didn't know one could remove your his own posts!).

As much as I really like Python (which I've been using full-time only
for the past two months) I really wish it did have regular private/
protected/public methods.

What for ? What you need is a way to tell the client code what's part of
the interface and what's implementation detail. From experience (*years*
fo experience), no one in it's own mind will mess with implementation
unless he has a very compelling reason _and_ is willing to pay the price
("shit, I broke everything... Ok, my fault.")

I'm building an application that can be extended by the users and I
really wish there was a solid way to prevent them from accessing parts
of the application that they shouldn't access

In Python, "shouldn't access" is spelled with a single leading
underscore !-)

or to provide read-only
access. I.e. right now I'm working on the graphical client which
potentially could be rewritten entirely by the users. It is necessary
and perfectly reasonable for the client module to access some of the
objects to be represented graphically, but those objects shouldn't be
modifiable by it.

Why so ? At worst, they'll break everything. So what ? As long as they
mess with your implementation, they are responsible for what happens.
OTHO, someone may have a perfectly valid reason to rewrite parts (or
whole) of your GUI - and he'll just love you for not standing in the way.

I now wonder, would developing the graphical client as an entirely
separate application, communicating with the server via the localhost
network interface and messages, solve the problem?

*which* problem ? Seriously ? What do you fear ? Extension code breaking
your app ? How is that *your* problem (I mean, as long as you
explicitely told the user what was part of the API and what wasn't ?).

What if your program was written in C, distributed only as compiled
machine code, and one of your users decided to make random edits in the
binary code ? Would you feel responsible ? *Nothing* in this world is
idiot-proof, so don't waste time trying to protect idiots from themselves.

 

[Emanuele D'Arrigo]

Why so ? At worst, they'll break everything.

-IF- the application was single-user yes, it wouldn't be a big deal.
But as it is potentially multi-user, I don't want one party to corrupt
the application for everybody else. Say I'm writing a multi-player
version of a card game (I'm not). For the sake of the argument let's
imagine that the players are all playing on the same computer, taking
turns. However, they are using a GUI written by one of the players who
unbeknown to them, has written it to modify the game state
appropriately and give himself the right cards at the right time. If
the game state is read-only and can only be queried but not modified
by the GUI, the player can rewrite the GUI but cannot cheat. Isn't
this a legitimate concern?

Manu

 

[rdmurray]

-IF- the application was single-user yes, it wouldn't be a big deal.
But as it is potentially multi-user, I don't want one party to corrupt
the application for everybody else. Say I'm writing a multi-player
version of a card game (I'm not). For the sake of the argument let's
imagine that the players are all playing on the same computer, taking
turns. However, they are using a GUI written by one of the players who
unbeknown to them, has written it to modify the game state
appropriately and give himself the right cards at the right time. If
the game state is read-only and can only be queried but not modified
by the GUI, the player can rewrite the GUI but cannot cheat. Isn't
this a legitimate concern?

In that case, you've got much bigger problems than a lack of private
methods. As someone else pointed out, _no_ language is secure in the
face of this requirement.

Proving this kind of interface requires a lot of careful security oriented
thinking. Whole operating systems have been designed to address these
kinds of issues...

--RDM

 

[greg]

-IF- the application was single-user yes, it wouldn't be a big deal.
But as it is potentially multi-user, I don't want one party to corrupt
the application for everybody else.

In that case you definitely want a client-server architecture,
with the server managing all the critical data.

 

[Emanuele D'Arrigo]

In that case you definitely want a client-server architecture,
with the server managing all the critical data.

Yep, I agree, I think that's the way to go and although trickier it
allows for some neatness and flexibility.

Thank you!

Manu

 

[Bruno Desthuilliers]

Emanuele D'Arrigo a écrit :

-IF- the application was single-user yes, it wouldn't be a big deal.
But as it is potentially multi-user, I don't want one party to corrupt
the application for everybody else.

A multi-users application with a GUI usually implies that it's a
client-server app with the GUI deployed is on each client and the domain
logic hosted on the server.

 

[boyombo]

Emanuele D'Arrigo a écrit :



A multi-users application with a GUI usually implies that it's a
client-server app with the GUI deployed is on each client and the domain
logic hosted on the server.

This is assuming the 'BAD GUY' does not have access to the server
code, right?