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

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

How to tell Script to use pythonw.exe ?

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

Contents

  How to tell Script to use pythonw.exe ? goldtech <leegold@operamail.com> - 2013-07-02 18:20 -0700
    Re: How to tell Script to use pythonw.exe ? goldtech <leegold@operamail.com> - 2013-07-02 18:28 -0700
      Re: How to tell Script to use pythonw.exe ? Tim Roberts <timr@probo.com> - 2013-07-02 20:43 -0700
        Re: How to tell Script to use pythonw.exe ? Νίκος <nikos@superhost.gr> - 2013-07-03 18:22 +0300
          Re: How to tell Script to use pythonw.exe ? Νίκος <nikos@superhost.gr> - 2013-07-03 19:50 +0300
            Re: How to tell Script to use pythonw.exe ? alex23 <wuwei23@gmail.com> - 2013-07-04 11:28 +1000
          Re: How to tell Script to use pythonw.exe ? Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-07-03 09:36 -0700
    Re: How to tell Script to use pythonw.exe ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-03 01:29 +0000
    Re: How to tell Script to use pythonw.exe ? Andrew Berg <robotsondrugs@gmail.com> - 2013-07-02 20:34 -0500
    DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Tim Golden <mail@timgolden.me.uk> - 2013-07-03 08:34 +0100
    Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Chris Angelico <rosuav@gmail.com> - 2013-07-03 17:41 +1000
    Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Andrew Berg <robotsondrugs@gmail.com> - 2013-07-03 03:28 -0500
    Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Tim Golden <mail@timgolden.me.uk> - 2013-07-03 09:51 +0100
    Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Tim Chase <python.list@tim.thechases.com> - 2013-07-03 07:50 -0500
    Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Tim Golden <mail@timgolden.me.uk> - 2013-07-03 14:00 +0100
      Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-03 13:19 +0000
        Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Jeff Schwab <jeff@schwabcenter.com> - 2013-07-03 09:22 -0400
        Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-07-03 18:11 -0400
        Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-03 17:35 -0600
        Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Wayne Werner <wayne@waynewerner.com> - 2013-07-04 09:08 -0500
        Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Andrew Berg <robotsondrugs@gmail.com> - 2013-07-04 17:12 -0500
        Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Chris Angelico <rosuav@gmail.com> - 2013-07-05 08:39 +1000
    Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?] Chris Angelico <rosuav@gmail.com> - 2013-07-04 00:00 +1000

Page 2 of 2 — ← Prev page 1 [2]

#49905 — Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?]

On 2013.07.04 09:08, Wayne Werner wrote:
> powershell -ExecutionPolicy Bypass -File ...
> 
> 
> \o/
> 
> Microsoft "security" at it again! (reminds me a bit of just pushing 
> "Cancel" to log into windows 98, I think it was)
>From an MSDN page linked in one of the answers:
> Now, why is
> 
>     PowerShell.exe –ExecutionPolicy Bypass –File c:\temp\bad-script.ps1
> 
> not a security bug? Ultimately, if bad code has the ability to run this code, it already has control of the machine.
http://blogs.msdn.com/b/powershell/archive/2008/09/30/powershell-s-security-guiding-principles.aspx

If an attacker can run code, he/she already has the capability to well, run code.
-- 
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1

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

#49908 — Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?]

On Fri, Jul 5, 2013 at 8:12 AM, Andrew Berg <robotsondrugs@gmail.com> wrote:
> On 2013.07.04 09:08, Wayne Werner wrote:
>> powershell -ExecutionPolicy Bypass -File ...
>>
>>
>> \o/
>>
>> Microsoft "security" at it again! (reminds me a bit of just pushing
>> "Cancel" to log into windows 98, I think it was)
> From an MSDN page linked in one of the answers:
>> Now, why is
>>
>>     PowerShell.exe –ExecutionPolicy Bypass –File c:\temp\bad-script.ps1
>>
>> not a security bug? Ultimately, if bad code has the ability to run this code, it already has control of the machine.
> http://blogs.msdn.com/b/powershell/archive/2008/09/30/powershell-s-security-guiding-principles.aspx
>
> If an attacker can run code, he/she already has the capability to well, run code.

Well, the whole point of sandboxing is to allow some code and not
other - look at web browser scripts. You can run your JavaScript code
on someone else's machine without the capability to run arbitrary
code.

What this proves is that PowerShell is not a sandboxing environment.
It has just two states: Trusted and untrusted. Untrusted code may not
run. Trusted code has full access as though the administrator typed
the commands by hand.

Unix has measures to prevent a running process from having full
control over the system, but even there, privilege escalation attacks
(usually involving some application that runs as root) have been
known. Restricting a running binary (as opposed to creating an
interpreted and very slow language) is a distinctly hard problem.

ChrisA

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

#49734 — Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?]

On Wed, Jul 3, 2013 at 10:50 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 2013-07-03 09:51, Tim Golden wrote:
>> We can certainly agree on this. I can't count the number of emails
>> I've deleted as too hot-headed in response to dismissive comments
>> about Windows as a platform. Some of them, at least, appear to be
>> from people who last actually used Windows back in the 9x days when
>> the command window was very limited indeed.
>
> I guess one of my biggest frustrations with the cmd.exe (and
> command.com) interpreters is that argument processing is left to the
> application, so each application may do it slightly differently:
>
>   C:\temp\> find weather *.py
>   FIND: Parameter format not correct
>   C:\temp\> find "weather" *.py
>   ---------- WFD.PY
>   weather = Weather(lat, lon)
>   C:\temp\> findstr weather *.py
>   wfd.py: weather = Weather(lat, lon)
>   C:\temp\> findstr "weather" *.py
>   wfd.py: weather = Weather(lat, lon)
>
> And more maddeningly:
>
>   C:\temp\> start file.txt
>   ... opens the file correctly in Notepad
>   C:\temp\> start "file with space.txt"
>   ... opens a new dos box with the name "file with space.txt" rather
>       than opening the file
>   C:\temp\> start "" "file with space.txt"
>   ... opens the file correctly in Notepad
>
> It's the little inconsistencies like this that wear daily on me.  That
> and the lack of built-in utilities, so I'm regularly adding GNU tools
> on new boxes.

The issue you have there is mainly that the quotes are serving double
purpose. Yes, they delimit and thus can be used to surround a file
name with spaces in it, but they're also significant to a couple of
apps (FIND uses them to indicate the search string, START looks for a
quoted argument to use as the title). I'm not entirely sure how it's
done under the covers; C code looking at argc/argv sees quoted
arguments without their quotes, exactly as I would expect on Unix, and
yet the convention is to notice the quotes.

The issue with START is 100% understandable and 100% annoying.

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web