Preventing execution of a method

Discussion in 'Python' started by Emanuele D'Arrigo, Dec 11, 2008.

  1. 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
    Emanuele D'Arrigo, Dec 11, 2008
    #1
    1. Advertising

  2. Emanuele D'Arrigo

    alex23 Guest

    On Dec 12, 2:07 am, "Emanuele D'Arrigo" <> wrote:
    > 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.
    alex23, Dec 11, 2008
    #2
    1. Advertising

  3. Emanuele D'Arrigo

    Guest

    On Thu, 11 Dec 2008 at 08:16, alex23 wrote:
    > On Dec 12, 2:07 am, "Emanuele D'Arrigo" <> wrote:
    >> 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.


    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
    , Dec 11, 2008
    #3
  4. Emanuele D'Arrigo

    MRAB Guest

    alex23 wrote:
    > On Dec 12, 2:07 am, "Emanuele D'Arrigo" <> wrote:
    >> 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.
    >

    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.
    MRAB, Dec 11, 2008
    #4
  5. Emanuele D'Arrigo

    alex23 Guest

    On Dec 12, 2:35 am, wrote:
    > 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

    >>> import module as m
    >>> m.__f

    <function __f at 0x00B80FB0>
    >>> m.__F

    <class 'module.__F'>
    >>> f = m.__F()
    >>> f.__f

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    AttributeError: '__F' object has no attribute '__f'
    >>> f._F__f

    <bound method __F.__f of <module.__F object at 0x00B89B30>>
    alex23, Dec 11, 2008
    #5
  6. Emanuele D'Arrigo

    alex23 Guest

    On Dec 12, 3:22 am, alex23 <> wrote:
    > On Dec 12, 2:35 am, wrote:
    >
    > > 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:


    And of course -now- I realise that the OP was asking for protecting
    methods. Please disregard my last post :)
    alex23, Dec 11, 2008
    #6
  7. Emanuele D'Arrigo

    r Guest

    > 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. ;)
    r, Dec 11, 2008
    #7
  8. 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
    Emanuele D'Arrigo, Dec 11, 2008
    #8
  9. 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, Dec 11, 2008
    #9
  10. 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.
    Bruno Desthuilliers, Dec 11, 2008
    #10
  11. On Dec 11, 7:48 pm, Bruno Desthuilliers
    <> wrote:
    > > 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.


    -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
    Emanuele D'Arrigo, Dec 11, 2008
    #11
  12. Emanuele D'Arrigo

    Guest

    On Thu, 11 Dec 2008 at 13:41, Emanuele D'Arrigo wrote:
    > On Dec 11, 7:48 pm, Bruno Desthuilliers
    > <> wrote:
    >>> 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.

    >
    > -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
    , Dec 11, 2008
    #12
  13. Emanuele D'Arrigo

    greg Guest

    Emanuele D'Arrigo wrote:

    > -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.

    --
    Greg
    greg, Dec 11, 2008
    #13
  14. On Dec 11, 11:46 pm, greg <> wrote:
    > Emanuele D'Arrigo wrote:
    > > -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.


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

    Thank you!

    Manu
    Emanuele D'Arrigo, Dec 12, 2008
    #14
  15. Emanuele D'Arrigo a écrit :
    > On Dec 11, 7:48 pm, Bruno Desthuilliers
    > <> wrote:
    >>> 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.

    >
    > -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.
    Bruno Desthuilliers, Dec 12, 2008
    #15
  16. Emanuele D'Arrigo

    boyombo Guest

    On Dec 12, 9:09 am, Bruno Desthuilliers <bruno.
    > wrote:
    > Emanuele D'Arrigo a écrit :
    >
    > > On Dec 11, 7:48 pm, Bruno Desthuilliers
    > > <> wrote:
    > >>> 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.

    >
    > > -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.


    This is assuming the 'BAD GUY' does not have access to the server
    code, right?
    boyombo, Dec 13, 2008
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Itai
    Replies:
    0
    Views:
    440
  2. MWells
    Replies:
    3
    Views:
    828
    John Saunders
    Jan 12, 2005
  3. Joris Gillis
    Replies:
    3
    Views:
    487
    Joris Gillis
    Oct 11, 2004
  4. Francis Hwang
    Replies:
    15
    Views:
    216
    Francis Hwang
    Jul 9, 2005
  5. Kyung won Cheon
    Replies:
    0
    Views:
    200
    Kyung won Cheon
    Nov 21, 2008
Loading...

Share This Page