FAQ
I want that a script should only be executed when it is called from another script and should not be directly executable through linux command line.


Like, I have two scripts "scrip1.py" and "script2.py" and there is a line in "script1.py" to call "script2.py" as subprocess.call(["python", "script2.py"]).


Then this is should call script2 but I should not be able to directly call script2 as $python script2.py

Search Discussions

  • Michael Torrie at Nov 25, 2013 at 2:58 am

    On 11/24/2013 06:55 PM, Himanshu Garg wrote:
    I want that a script should only be executed when it is called from
    another script and should not be directly executable through linux
    command line.

    Like, I have two scripts "scrip1.py" and "script2.py" and there is a
    line in "script1.py" to call "script2.py" as
    subprocess.call(["python", "script2.py"]).

    Then this is should call script2 but I should not be able to directly
    call script2 as $python script2.py

    I'm not totally sure what you mean, but if you want to prevent the
    script from doing anything when run from the command line but have it do
    something when imported as a module then just put this at the beginning:


    if __name__ == "__main__":
         import sys
         sys.exit(0)
  • Chris Angelico at Nov 25, 2013 at 3:15 am

    On Mon, Nov 25, 2013 at 12:55 PM, Himanshu Garg wrote:
    I want that a script should only be executed when it is called from another script and should not be directly executable through linux command line.

    Like, I have two scripts "scrip1.py" and "script2.py" and there is a line in "script1.py" to call "script2.py" as subprocess.call(["python", "script2.py"]).

    Then this is should call script2 but I should not be able to directly call script2 as $python script2.py

    Easy! Just have your subprocess.call pass a special argument, which
    you then look for in script2:


    subprocess.call(["python", "script2.py","confirm"])


    # script2.py
    import sys
    if "confirm" not in sys.argv:
         print("This script should not be run directly.")
         sys.exit(1)


    # rest of script2.py follows


    ChrisA
  • Dave Angel at Nov 25, 2013 at 3:20 am

    On Sun, 24 Nov 2013 17:55:08 -0800 (PST), Himanshu Garg wrote:
    Like, I have two scripts "scrip1.py" and "script2.py" and there is
    a line in "script1.py" to call "script2.py" as
    subprocess.call(["python", "script2.py"]).

    Then this is should call script2 but I should not be able to
    directly call script2 as $python script2.py


    Are you really trying to protect against yourself accidentally
    invoking it or someone maliciously doing it?


    I would probably give scrpt2 an obnoxious name like
    htrerttcdrrthyyh.py or put it in an obscure directory. But if you
    explain the rationale we might come up with something better.


    How about naming it dontrunme.py ?


    --
    DaveA
  • Peter Otten at Nov 25, 2013 at 8:12 am

    Himanshu Garg wrote:


    I want that a script should only be executed when it is called from
    another script and should not be directly executable through linux command
    line.

    Like, I have two scripts "scrip1.py" and "script2.py" and there is a line
    in "script1.py" to call "script2.py" as subprocess.call(["python",
    "script2.py"]).

    Then this is should call script2 but I should not be able to directly call
    script2 as $python script2.py

    Put the toplevel code into a function, i. e. change


    #script2.py old
    print "hello from script2"


    to


    # script2.py new


    def f(): # you should pick a descriptive name instead of f
         print "hello from script2"


    and then import it from script1 and invoke the function:


    # script1.py old
    #...
    subprocess.call("python", "script2.py")
    #...


    # script1.py new
    import script1
    #...
    script.f()
    #...
  • Himanshu Garg at Nov 25, 2013 at 10:52 am
    I was also thinking to add a sys argument when invoking script and check it.


    My motive is "I will give scripts to somebody else and he should not run the script directly without running the parent script".
  • Dave Angel at Nov 25, 2013 at 12:16 pm

    On Mon, 25 Nov 2013 02:52:46 -0800 (PST), Himanshu Garg wrote:
    My motive is "I will give scripts to somebody else and he should
    not run the script directly without running the parent script".


    Perhaps it should be a module, not a script. Have it protect itself
    with the usual if __name__ == "__main__"


    And of course it gets executed by an import and a call.


    --
    DaveA
  • Rick Johnson at Nov 26, 2013 at 2:28 am

    On Monday, November 25, 2013 4:52:46 AM UTC-6, Himanshu Garg wrote:


    My motive is "I will give scripts to somebody else and he
    should not run the script directly without running the
    parent script".

    The only sure fire method to prevent a file containing
    Python code from executing on a machine with Python
    installed is to use an extension that the system will not
    associate with Python.


      ScriptFolder/
        script.py
        mod_1.ignore
        mod_2.ignore
        ...


    Of course, any other Python module that needs to leverage
    the API contained within the "aliased mod files" will need
    to do so *manually*:


      1. Read the file from disc
      2. Evaluate the file contents and make callable
      3. Close the file


    Sounds like your distributing a Python application and need
    a simplistic method by which "non-techies" can run the code,
    but as we all know:


      "fools are too cleaver!"


    Of course a smarty pants could could change the extension to
    "py[w]", but that would be violating your interface. :)


    Another choice would be to use a package.


      ScriptPackageFolder/
        __init__.py
        __script.py
        mod_1.py
        mod_2.py
        ...


    But nothing could stop them from accessing the contents of
    the package directory.


    A third alternative would be to install the support modules
    in a place that the user would be unlikely to look and then
    place a mainscript somewhere that is easily accessible. But
    even this method will not prevent the running of py scripts.


    Sounds like my first offering is the best. At least with
    that method they would be forced into an explicit act of
    renaming the file before they violate your interface.
  • Chris Angelico at Nov 26, 2013 at 2:41 am

    On Tue, Nov 26, 2013 at 1:28 PM, Rick Johnson wrote:
    The only sure fire method to prevent a file containing
    Python code from executing on a machine with Python
    installed is to use an extension that the system will not
    associate with Python.

    ScriptFolder/
    script.py
    mod_1.ignore
    mod_2.ignore
    ...

    Windows:
    C:\Documents and Settings\M>copy con test.ignore
    print("Hello, world!")
    ^Z
             1 file(s) copied.


    C:\Documents and Settings\M>python test.ignore
    Hello, world!


    Linux:
    gideon at gideon:~$ cat >test.ignore
    print("Hello, world!")
    gideon at gideon:~$ python test.ignore
    Hello, world!


    Totally sure-fire. Absolutely prevents any execution until it's
    renamed. By the way, what does "associate" mean, and what does it have
    to do with file names?


    gideon at gideon:~$ cat >test.ignore
    #!/usr/bin/python
    print("Hello, world!")
    gideon at gideon:~$ chmod +x test.ignore
    gideon at gideon:~$ ./test.ignore
    Hello, world!


    ChrisA
  • Chris Angelico at Nov 26, 2013 at 11:09 pm

    On Wed, Nov 27, 2013 at 4:25 AM, Dennis Lee Bieber wrote:
    On Tue, 26 Nov 2013 13:41:07 +1100, Chris Angelico <rosuav@gmail.com>
    declaimed the following:
    Totally sure-fire. Absolutely prevents any execution until it's
    renamed. By the way, what does "associate" mean, and what does it have
    to do with file names?
    Windows-speak...

    Where UNIX/Linux relies upon the first line of a script to identify
    what executable is used to process it (the #! line), Windows uses a linked
    pair of registry entries

    Yeah. It's usually a GUI feature, not a command-line one, and it
    certainly has nothing to do with preventing execution - it is strictly
    a convenience. In the OS/2 WorkPlace Shell, you can associate files
    with programs by either a filename pattern (which doesn't have to be
    star-dot-something - I've always had an association "Makefile.*"),
    file type (not MIME type - this system predates that - but a category
    that files can be added to), object class (when a file is created, it
    can be a subclass of WPFile, like DeScribeDocument), or manually on an
    individual file, which is then stored as an extended attribute on that
    file. But it's still nothing more than a shortcut - it lets you put a
    program into the "Open ->" menu, and (optionally) choose one program
    from said menu to be the default, which is run when you double-click
    on the file's icon (or call the associated method on the file's object
    - everything in the WPS is an object, and naturally any program can
    send any object any method). Deleting or breaking an association
    doesn't stop you dragging the icon onto the program - which is
    sometimes necessary in situations where information isn't properly
    carried through. It certainly does not stop Python from executing a
    script.


    My point was that Rick had made the assumption that the GUI was
    *everything* and that users were able to do nothing beyond
    double-clicking on icons - and that he did not mention this
    assumption, suggesting he was unaware that he had made it.


    ChrisA
  • Rick Johnson at Nov 27, 2013 at 1:56 am

    On Tuesday, November 26, 2013 5:09:13 PM UTC-6, Chris Angelico wrote:
    My point was that Rick had made the assumption that the GUI was
    *everything* and that users were able to do nothing beyond
    double-clicking on icons

    For some people the GUI *is* everything.


    Most people are unaware that life *even* exists beyond the
    "point and click". Heck, If you opened a command prompt in
    front of them, they'd run and hide in a closet for the next
    three hours consumed with fear. They'd probably convince
    themselves that "cryptic commands" in a "black window" could
    be nothing less than sorcery -- and that's usually when the
    pitchforks come out.


    Chris, it's obvious you need to climb down from the tower
    and mingle with the peasants a bit -- don't worry, we'll
    delouse you when you get back ;-)
  • Chris Angelico at Nov 27, 2013 at 2:39 am

    On Wed, Nov 27, 2013 at 12:56 PM, Rick Johnson wrote:
    Most people are unaware that life *even* exists beyond the
    "point and click". Heck, If you opened a command prompt in
    front of them, they'd run and hide in a closet for the next
    three hours consumed with fear. They'd probably convince
    themselves that "cryptic commands" in a "black window" could
    be nothing less than sorcery -- and that's usually when the
    pitchforks come out.

    [citation needed]

    Chris, it's obvious you need to climb down from the tower
    and mingle with the peasants a bit -- don't worry, we'll
    delouse you when you get back ;-)

    My mother used to be the sort who didn't even use computers if she
    didn't have to. Now, she happily uses Debian Wheezy on her laptop, and
    if I ask her to pull up a terminal and type something, she knows how
    to do that.


    Stephanie Gibson is a soprano from the operatic society I work with.
    She uses a Mac, probably the strongest "use a GUI not a terminal"
    system in popular use today. And when she had networking issues, I was
    able to show her how to pull up a terminal, and she handled it just
    fine - to the point of grokking how to skim the output of ifconfig for
    the pertinent bits, without even being instructed.


    I have worked with innumerable people. Never yet have I found a single
    one who ran away in fear, pulled out pitchforks, or anything of the
    sort. Yes, there are plenty of people who don't like to memorize
    commands (my former boss thought that all command-line UIs are by
    definition cryptic, I think because he came across a few
    poorly-documented ones), but very few who can't accept dictation - and
    much more easily than mouse clicks can be dictated.


    ChrisA
  • Steven D'Aprano at Nov 26, 2013 at 3:09 am

    On Mon, 25 Nov 2013 18:28:42 -0800, Rick Johnson wrote:

    On Monday, November 25, 2013 4:52:46 AM UTC-6, Himanshu Garg wrote:

    My motive is "I will give scripts to somebody else and he should not
    run the script directly without running the parent script".
    The only sure fire method to prevent a file containing Python code from
    executing on a machine with Python installed is to
    [snip bad advice]


    ... is to delete Python from the system, or the Python code. Or both.


    If Python can read a file, it can exec it.


    I suppose you could use file permissions and ACLs to prevent Python from
    reading the file, rather than delete it, but given the possibility of
    privilege-escalation security vulnerabilities, even that's not sure-fire.




    --
    Steven
  • Rick Johnson at Nov 26, 2013 at 3:45 am

    On Monday, November 25, 2013 8:41:07 PM UTC-6, Chris Angelico wrote:


    Totally sure-fire. Absolutely prevents any execution until it's
    renamed.

    Doh! It seems Python's quite the sneaky little snake!

    By the way, what does "associate" mean, and what does it have
    to do with file names?

    Hmm, I did not see his "command line snip-it" and assumed his users where not "command line savvy", therefor they would be running the script via a mouse click -- still probably not "sure fire" advice either.


    Okay, Rick was wrong once. get over it! :-P"
  • Larry Hudson at Nov 26, 2013 at 8:10 am

    On 11/24/2013 07:20 PM, Dave Angel wrote:


    Are you really trying to protect against yourself accidentally invoking it or someone
    maliciously doing it?
    I would probably give scrpt2 an obnoxious name like htrerttcdrrthyyh.py or put it in an obscure
    directory. But if you explain the rationale we might come up with something better.

    How about naming it dontrunme.py ?

    Totally different subject of course, but this reminds me of an editor I used many years ago
    (probably with CP/M) that used "delete.me" as its default filename. I don't remember for sure
    now, but I think it was an editor called Mince (Mince Is Not Complete EMACS).


           -=- Larry -=-

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedNov 25, '13 at 1:55a
activeNov 27, '13 at 2:39a
posts15
users8
websitepython.org

People

Translate

site design / logo © 2022 Grokbase