Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #60395 > unrolled thread

Excute script only from another file

Back to article view | Back to comp.lang.python

Contents

  Excute script only from another file Himanshu Garg <hgarg.india@gmail.com> - 2013-11-24 17:55 -0800
    Re: Excute script only from another file Chris Angelico <rosuav@gmail.com> - 2013-11-25 14:15 +1100
    Re: Excute script only from another file Dave Angel <davea@davea.name> - 2013-11-24 22:20 -0500
      Re: Excute script only from another file Larry Hudson <orgnut@yahoo.com> - 2013-11-26 00:10 -0800
    Re: Excute script only from another file Michael Torrie <torriem@gmail.com> - 2013-11-24 19:58 -0700
    Re: Excute script only from another file Peter Otten <__peter__@web.de> - 2013-11-25 09:12 +0100
    Re: Excute script only from another file Himanshu Garg <hgarg.india@gmail.com> - 2013-11-25 02:52 -0800
      Re: Excute script only from another file Dave Angel <davea@davea.name> - 2013-11-25 07:16 -0500
      Re: Excute script only from another file Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-25 18:28 -0800
        Re: Excute script only from another file Chris Angelico <rosuav@gmail.com> - 2013-11-26 13:41 +1100
          Re: Excute script only from another file Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-25 19:45 -0800
        Re: Excute script only from another file Steven D'Aprano <steve@pearwood.info> - 2013-11-26 03:09 +0000
        Re: Excute script only from another file Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-11-26 12:25 -0500
        Re: Excute script only from another file Chris Angelico <rosuav@gmail.com> - 2013-11-27 10:09 +1100
          Re: Excute script only from another file Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-26 17:56 -0800
            Re: Excute script only from another file Chris Angelico <rosuav@gmail.com> - 2013-11-27 13:39 +1100

#60395 — Excute script only from another file

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

[toc] | [next] | [standalone]

#60396

On Mon, Nov 25, 2013 at 12:55 PM, Himanshu Garg <hgarg.india@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#60397

On Sun, 24 Nov 2013 17:55:08 -0800 (PST), Himanshu Garg 
<hgarg.india@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#60490

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

[toc] | [prev] | [next] | [standalone]

#60398

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)

[toc] | [prev] | [next] | [standalone]

#60402

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()
#...

[toc] | [prev] | [next] | [standalone]

#60407

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

[toc] | [prev] | [next] | [standalone]

#60410

On Mon, 25 Nov 2013 02:52:46 -0800 (PST), Himanshu Garg 
<hgarg.india@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#60478

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.

[toc] | [prev] | [next] | [standalone]

#60479

On Tue, Nov 26, 2013 at 1:28 PM, Rick Johnson
<rantingrickjohnson@gmail.com> 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@gideon:~$ cat >test.ignore
print("Hello, world!")
gideon@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@gideon:~$ cat >test.ignore
#!/usr/bin/python
print("Hello, world!")
gideon@gideon:~$ chmod +x test.ignore
gideon@gideon:~$ ./test.ignore
Hello, world!

ChrisA

[toc] | [prev] | [next] | [standalone]

#60483

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"

[toc] | [prev] | [next] | [standalone]

#60481

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

[toc] | [prev] | [next] | [standalone]

#60529

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


C:\Users\Wulfraed\Documents>assoc .py
.py=Python.File

C:\Users\Wulfraed\Documents>ftype python.file
python.file="C:\PYTHON~2\Python27\python.exe" "%1" %*

C:\Users\Wulfraed\Documents>


	"ftype" takes a type label and defines the command line used to execute
that file type (or otherwise open the file... ).

	"assoc" takes a file extension and "associates" it with the type label
-- allows multiple extensions to be linked to one command line

.py=Python.File
.pyc=Python.CompiledFile
.pyo=Python.CompiledFile
.pys=pysFile
.pyw=Python.NoConFile


Python.CompiledFile="C:\PYTHON~2\Python27\python.exe" "%1" %*
Python.File="C:\PYTHON~2\Python27\python.exe" "%1" %*
Python.NoConFile="C:\PYTHON~2\Python27\pythonw.exe" "%1" %*

(No idea where .pys came from -- it has no defined executor)

	These are how one can do things like

C:\Users\Wulfraed\Documents>scite t.py

C:\Users\Wulfraed\Documents>python t.py
Goodbye

C:\Users\Wulfraed\Documents>t.py
Goodbye

C:\Users\Wulfraed\Documents>t
Goodbye

	There's another environment variable that defines what order to search
extensions when not provided (as in the last sample above), as one may have
a t.py, t.bat, t.doc, etc.

PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.py;.pyw

Hmmm, think I need to edit that... shove the .py* behind .bat -- I don't
use the others so why have the system try to find them first. I'd add
powershell but its designed for security and pretty much needs to be
manually invoked.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#60548

On Wed, Nov 27, 2013 at 4:25 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> 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

[toc] | [prev] | [next] | [standalone]

#60563

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 ;-)

[toc] | [prev] | [next] | [standalone]

#60567

On Wed, Nov 27, 2013 at 12:56 PM, Rick Johnson
<rantingrickjohnson@gmail.com> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web