How to protect Python source from modification

[Frank Millman]

Dennis Lee Bieber wrote:
> On 13 Sep 2005 01:00:37 -0700, "Frank Millman" <frank at chagford.com>
> declaimed the following in comp.lang.python:
>
>
> > 2. I am a great believer in 'field-by-field' validation when doing data
> > entry, instead of filling in the entire form, submitting it, and then
> > being informed of all the errors. I can inform a user straight away if
> > they try to do something they are not entitled to.
> >
> 	Ensuring a field is numeric (with range checking) or string is one
> thing... But if a certain user is not even supposed to see a field, or
> only have read-only access, those could be determined at the server side
> when generating the form (okay, that was phrased more as a web-page
> scheme, but...) Better that low-privilege users never even learn of the
> additional data fields rather than be tempted by the "forbidden fruit"
> <G>
>

Food for thought - thanks

> > 3. I can cater for the situation where a user may not have permission
> > to do something, but they can call a supervisor who can override this.
> > I have seen solutions which involve prompting for a password, but this
> > has to be programmed in at every place where it might be required. I
> > allow the supervisor to enter their userid and password, and my program
> > reads in their permissions, which become the active ones until
> > cancelled. I create a flashing red border around the window to warn
> > them not to forget.
> >
> 	I suspect such an override could still be done through the server
> side. Not sure of the "programmed in at every place" concern -- it
> sounds like just an exception handler with retry (and if it were done
> via web forms, it would be the server detecting "no privilege" and
> returning the override log-in form). I'd be more concerned that the
> override doesn't go away after the transaction is completed... To me, if
> a lowly user needs to have a supervisor unlock operations -- and the
> supervisor then walks away while the higher privileges are active, it is
> a sign of either poor security practices, or a need to grant that user
> more privileges.
>
> 	Imagine a store where supervisor approval is needed for any check
> over a certain amount... You don't want the supervisor to key in their
> approval code on a register and walk away leaving that code active (and
> letting the clerk then enter dozens of high value checks without calling
> for a supervisor). The code should only be active for the completion of
> the check approval and then automatically reset to the regular clerk's
> mode of operation.
>

H'mm, more food for thought.

The advantage of my approach is that no additional programming is
required. I have a very flexible security model, which is entirely
user-definable. If any user finds that they are blocked from doing
something, they can call anyone who does have that permission, without
exiting from their position in the app. The other person can key in
their userid and password, perform the required action, and the
original user can carry on. You are right that the danger is that the
second person forgets to cancel their code. That is why I create a
flashing red border.

This is how it works from a user perspective. There is a hot-key,
Ctrl-U, which can be pressed at any prompt (wxPython makes this easy).
If pressed, I pop up a box asking for userid and password. If accepted,
I save the original user's permissions, read in the new user's
permissions, and create the flashing border. To cancel the setting, the
user simply presses Ctrl-U again, and everything is reset.

I think this works quite well, so I will run with it for now and see if
it causes any problems in practice.

Many thanks for the valuable comments.

Frank