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

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

Quotation Ugliness

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

Contents

  Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-25 18:18 -0600
    Re: Quotation Ugliness Tim Chase <python.list@tim.thechases.com> - 2014-11-25 18:40 -0600
      Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-25 19:18 -0600
        Re: Quotation Ugliness Chris Angelico <rosuav@gmail.com> - 2014-11-26 12:32 +1100
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 00:00 -0600
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 00:00 -0600
      Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-25 19:18 -0600
    Re: Quotation Ugliness Chris Angelico <rosuav@gmail.com> - 2014-11-26 11:44 +1100
      Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-25 19:20 -0600
      Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-25 19:20 -0600
        Re: Quotation Ugliness Tim Chase <python.list@tim.thechases.com> - 2014-11-25 19:44 -0600
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 00:01 -0600
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 00:01 -0600
    Re: Quotation Ugliness Ben Finney <ben+python@benfinney.id.au> - 2014-11-26 12:54 +1100
      Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 00:04 -0600
      Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 00:04 -0600
        Using a password with ‘sudo’ (was: Quotation Ugliness) Ben Finney <ben+python@benfinney.id.au> - 2014-11-26 18:02 +1100
        Re: Quotation Ugliness Chris Angelico <rosuav@gmail.com> - 2014-11-26 18:10 +1100
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 08:59 -0600
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 08:59 -0600
        Re: Quotation Ugliness Tim Chase <python.list@tim.thechases.com> - 2014-11-26 06:56 -0600
          Re: Quotation Ugliness Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-11-26 15:45 +0200
            Re: Quotation Ugliness Chris Angelico <rosuav@gmail.com> - 2014-11-27 01:37 +1100
            Re: Quotation Ugliness Tim Chase <python.list@tim.thechases.com> - 2014-11-26 08:26 -0600
            Re: Quotation Ugliness Chris Angelico <rosuav@gmail.com> - 2014-11-27 02:07 +1100
            Re: Quotation Ugliness Chris Angelico <rosuav@gmail.com> - 2014-11-27 02:09 +1100
              Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 09:36 -0600
              Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 09:36 -0600
                Re: Quotation Ugliness Chris Angelico <rosuav@gmail.com> - 2014-11-27 02:48 +1100
                  Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 09:55 -0600
                  Re: Quotation Ugliness random832@fastmail.us - 2014-11-26 11:00 -0500
                    Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 10:02 -0600
                    Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 10:02 -0600
                      Re: Quotation Ugliness Chris Angelico <rosuav@gmail.com> - 2014-11-27 03:13 +1100
                      Re: Quotation Ugliness random832@fastmail.us - 2014-11-26 11:16 -0500
                        Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 10:54 -0600
                        Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 10:54 -0600
                      Re: Quotation Ugliness alister <alister.nospam.ware@ntlworld.com> - 2014-11-26 16:45 +0000
                        Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 10:54 -0600
                  Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 09:55 -0600
                Re: Quotation Ugliness random832@fastmail.us - 2014-11-26 10:53 -0500
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 08:58 -0600
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 08:58 -0600
            Re: Quotation Ugliness Chris Angelico <rosuav@gmail.com> - 2014-11-27 02:06 +1100
            Re: Quotation Ugliness Tim Chase <python.list@tim.thechases.com> - 2014-11-26 09:23 -0600
            Re: Quotation Ugliness Ben Finney <ben+python@benfinney.id.au> - 2014-11-27 07:24 +1100
        Re: Quotation Ugliness random832@fastmail.us - 2014-11-26 09:12 -0500
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 09:02 -0600
          Re: Quotation Ugliness Tim Daneliuk <tundra@tundraware.com> - 2014-11-26 09:02 -0600
            Re: Quotation Ugliness random832@fastmail.us - 2014-11-26 10:16 -0500

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

#81590

On Wed, Nov 26, 2014, at 10:36, Tim Daneliuk wrote:
> The more I think about this, the more I think I am just going to look for
> the
> string 'sudo' anywhere in the argument.  This merely will force the user
> to
> enter their sudo password if detected.  If it turns out to be a false
> positive,
> no harm will be done and the password will just go unused.

You could detect if the remote command on one of the target machines
prompts for a password, and if so present that prompt to the user then.

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

#81571

On 11/26/2014 06:56 AM, Tim Chase wrote:
> On 2014-11-26 00:04, Tim Daneliuk wrote:
>> someprog.py uname && sudo cat /etc/sudoers
>>
>> vs.
>>
>> someprog.py uname && echo "sudo cat /etc/suoders"
>>
>>
>> In the first instance, I need the sudo passoword, in the second I
>> don't.
>
> This doesn't jibe with the pairs of quotes you sent and your request
> for nesting.  In most popular shells, the majority of your "quote"
> characters don't actually quote anything:
>
>    bash$ echo // hello
>    hello
>    bash$ echo /* hello */
>    [returns all the items in my root directory, the word "hello",
>    along with all the sub-directories in the current directory]
>    bash$ echo this#and#that
>    this#and#that
>    bash$ echo this # and #that
>    this
>
> and has problems with things like
>
>    someprog.py uname && su""do cat /etc/sudoers
>    someprog.py uname && s"ud"o cat /etc/sudoers
>
> which my shell will parse valid execution of sudo.

<SNIP>


I am not writing in bash,  but in python.

The specific program in question I am modifying is
one that takes a shell command and executes it remotely on many machines.
The problem I am trying to solve is to determine whether the user needs to
provide a sudo password or not.  Right now, the program just naively checks
the arguments to see if .startswith("sudo').  As the example given illustrates,
that clearly fails if the sudo is given later in a longer pipeline.

Scanning the whole argument string for 'sudo' is better but will yield
false positives if the string is inside a quote of some sort.  Since I have
to solve the problem for ' and " delimiters, I thought I'd generalize the solution
for other strings possibly being quoted by other delimiters.
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

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

#81573

On 11/26/2014 06:56 AM, Tim Chase wrote:
> On 2014-11-26 00:04, Tim Daneliuk wrote:
>> someprog.py uname && sudo cat /etc/sudoers
>>
>> vs.
>>
>> someprog.py uname && echo "sudo cat /etc/suoders"
>>
>>
>> In the first instance, I need the sudo passoword, in the second I
>> don't.
>
> This doesn't jibe with the pairs of quotes you sent and your request
> for nesting.  In most popular shells, the majority of your "quote"
> characters don't actually quote anything:
>
>    bash$ echo // hello
>    hello
>    bash$ echo /* hello */
>    [returns all the items in my root directory, the word "hello",
>    along with all the sub-directories in the current directory]
>    bash$ echo this#and#that
>    this#and#that
>    bash$ echo this # and #that
>    this
>
> and has problems with things like
>
>    someprog.py uname && su""do cat /etc/sudoers
>    someprog.py uname && s"ud"o cat /etc/sudoers
>
> which my shell will parse valid execution of sudo.

<SNIP>


I am not writing in bash,  but in python.

The specific program in question I am modifying is
one that takes a shell command and executes it remotely on many machines.
The problem I am trying to solve is to determine whether the user needs to
provide a sudo password or not.  Right now, the program just naively checks
the arguments to see if .startswith("sudo').  As the example given illustrates,
that clearly fails if the sudo is given later in a longer pipeline.

Scanning the whole argument string for 'sudo' is better but will yield
false positives if the string is inside a quote of some sort.  Since I have
to solve the problem for ' and " delimiters, I thought I'd generalize the solution
for other strings possibly being quoted by other delimiters.
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

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

#81577

On Thu, Nov 27, 2014 at 1:58 AM, Tim Daneliuk <tundra@tundraware.com> wrote:
> The specific program in question I am modifying is
> one that takes a shell command and executes it remotely on many machines.
> The problem I am trying to solve is to determine whether the user needs to
> provide a sudo password or not.  Right now, the program just naively checks
> the arguments to see if .startswith("sudo').  As the example given
> illustrates,
> that clearly fails if the sudo is given later in a longer pipeline.
>
> Scanning the whole argument string for 'sudo' is better but will yield
> false positives if the string is inside a quote of some sort.  Since I have
> to solve the problem for ' and " delimiters, I thought I'd generalize the
> solution
> for other strings possibly being quoted by other delimiters.

Tell whoever asked you to do this that it's a fundamentally impossible
task. Quotes have nothing to do with whether or not "sudo" is what
will be executed. Your only solutions will involve either parsing the
entire command line, exactly the way the shell does (including knowing
everything the shell knows at the far end, like command aliases), or
letting the shell do the parsing and then tinkering with what the
"sudo" command does. You can't easily and safely predict it based on
simple string processing.

ChrisA

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

#81607

On 2014-11-26 08:58, Tim Daneliuk wrote:
> On 11/26/2014 06:56 AM, Tim Chase wrote:
> > On 2014-11-26 00:04, Tim Daneliuk wrote:
> >> someprog.py uname && sudo cat /etc/sudoers
> >>
> >> vs.
> >>
> >> someprog.py uname && echo "sudo cat /etc/suoders"
> >>
> >>
> >> In the first instance, I need the sudo passoword, in the second I
> >> don't.
> >
> > This doesn't jibe with the pairs of quotes you sent and your
> > request for nesting.  In most popular shells, the majority of
> > your "quote" characters don't actually quote anything:
> >
> >    bash$ echo // hello
> >    // hello
> >    bash$ echo /* hello */
> >    [returns all the items in my root directory, the word "hello",
> >    along with all the sub-directories in the current directory]
> >    bash$ echo this#and#that
> >    this#and#that
> >    bash$ echo this # and #that
> >    this
> >
> > and has problems with things like
> >
> >    someprog.py uname && su""do cat /etc/sudoers
> >    someprog.py uname && s"ud"o cat /etc/sudoers
> >
> > which my shell will parse valid execution of sudo.
> 
> I am not writing in bash,  but in python.
> 
> The specific program in question I am modifying is one that takes a
> shell command and executes it remotely on many machines. 

While my examples used bash, it doesn't matter whether your local
code is Python, Perl, Ruby, Lua, or Visual Basic:  you have to parse
the string like it's the shell on those remote machines that parses
for whether sudo is used.  This could be bash, zsh, tcsh, sh, pdksh,
dash, or whatever.  The particular shell doesn't matter (in the
abstract). What matters is that you are checking whether a command
that will be processed by one of these remote shells will need a
password.  To do that, you need to parse the string as that
particular shell would.  Usually, on Linux boxes, this is bash, while
on FreeBSD defaults to tcsh, and OpenBSD defaults to pdksh.

Unless you successfully parse it like your target shell will, you
will have edge cases where the quoting fails.

-tkc

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

#81608

Tim Daneliuk <tundra@tundraware.com> writes:

> The problem I am trying to solve is to determine whether the user
> needs to provide a sudo password or not.

Again, the ‘sudo’ program itself will figure this out and ask for a
password if it needs one.

Examining the command line isn't enough. Even if you find a ‘sudo’
command there, there are common circumstances where no password is
needed. The program handles all this, you can't predict it from outside.

> Right now, the program just naively checks the arguments to see if
> .startswith("sudo'). As the example given illustrates, that clearly
> fails if the sudo is given later in a longer pipeline.

The problem as you've presented it requires you to re-implement the
command-line parsing from whatever command shell is used. You will
necessarily fall short of that, no matter what you do.

Your best course is to get the requirements changed, as they are
currently not implementable.

-- 
 \     “Facts are stubborn things; and whatever may be our wishes, our |
  `\   inclinations, or the dictates of our passion, they cannot alter |
_o__)        the state of facts and evidence.” —John Adams, 1770-12-04 |
Ben Finney

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

#81567

On Wed, Nov 26, 2014, at 01:04, Tim Daneliuk wrote:
> In this case, I am not trying to write a fullblown language or recover
> from syntax errors.   Here's a usecase - I want to know whether I need
> to use a sudo password when the user passes a command on the command line
> of a program:
> 
> someprog.py uname && sudo cat /etc/sudoers
> 
> vs.
> 
> someprog.py uname && echo "sudo cat /etc/suoders"
> 
> 
> In the first instance, I need the sudo passoword, in the second I don't.

I think first you need to understand how the command line works. Much of
this parsing - including both && and quotes - is handled by the shell
before your program ever sees it.

Imagine someprog.py is this very simple program:
import sys
print("%r" % (sys.argv,))

$ someprog.py uname
['someprog.py', 'uname']
$ someprog.py uname && sudo cat /etc/sudoers
['someprog.py', 'uname']
Password: {sudo executed independent of your program}
$ someprog.py uname && echo "sudo cat /etc/sudoers"
['someprog.py', 'uname']
sudo cat /etc/sudoers {echo executed independent of your program}
$ someprog.py uname "&&" sudo cat /etc/sudoers
['someprog.py', 'uname', '&&', 'sudo', 'cat', '/etc/sudoers']
$ someprog.py uname "&&" echo "sudo cat /etc/sudoers"
['someprog.py', 'uname', '&&', 'echo', 'sudo cat /etc/sudoers']
$ someprog.py 'uname && echo "sudo cat /etc/sudoers"'
['someprog.py', 'uname && echo "sudo cat /etc/sudoers"']

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

#81575

On 11/26/2014 08:12 AM, random832@fastmail.us wrote:
> On Wed, Nov 26, 2014, at 01:04, Tim Daneliuk wrote:
>> In this case, I am not trying to write a fullblown language or recover
>> from syntax errors.   Here's a usecase - I want to know whether I need
>> to use a sudo password when the user passes a command on the command line
>> of a program:
>>
>> someprog.py uname && sudo cat /etc/sudoers
>>
>> vs.
>>
>> someprog.py uname && echo "sudo cat /etc/suoders"
>>
>>
>> In the first instance, I need the sudo passoword, in the second I don't.
>
> I think first you need to understand how the command line works. Much of
> this parsing - including both && and quotes - is handled by the shell
> before your program ever sees it.
>

I am not writing in shell nor am I escaping to the shell locally for execution

someprog.py is a paramiko-based wrapper that executes the given command
on many machines remotely.  I (over) simplified the example and in my
haste introduced and incorrect idea.  What this should say is:

   someprog.py "uname && sudo cat /etc/sudoers"

  vs.

   someprog.py 'uname && echo "sudo cat /etc/suoders"'



-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

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

#81580

On 11/26/2014 08:12 AM, random832@fastmail.us wrote:
> On Wed, Nov 26, 2014, at 01:04, Tim Daneliuk wrote:
>> In this case, I am not trying to write a fullblown language or recover
>> from syntax errors.   Here's a usecase - I want to know whether I need
>> to use a sudo password when the user passes a command on the command line
>> of a program:
>>
>> someprog.py uname && sudo cat /etc/sudoers
>>
>> vs.
>>
>> someprog.py uname && echo "sudo cat /etc/suoders"
>>
>>
>> In the first instance, I need the sudo passoword, in the second I don't.
>
> I think first you need to understand how the command line works. Much of
> this parsing - including both && and quotes - is handled by the shell
> before your program ever sees it.
>

I am not writing in shell nor am I escaping to the shell locally for execution

someprog.py is a paramiko-based wrapper that executes the given command
on many machines remotely.  I (over) simplified the example and in my
haste introduced and incorrect idea.  What this should say is:

   someprog.py "uname && sudo cat /etc/sudoers"

  vs.

   someprog.py 'uname && echo "sudo cat /etc/suoders"'



-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

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

#81583

On Wed, Nov 26, 2014, at 10:02, Tim Daneliuk wrote:
>    someprog.py "uname && sudo cat /etc/sudoers"
> 
>   vs.
> 
>    someprog.py 'uname && echo "sudo cat /etc/suoders"'

I think it would be better to provide a general way for the user to
provide an input script as an option, rather than to specifically detect
the use of sudo. What if the command is a shell script that calls sudo
within the script?

[toc] | [prev] | [standalone]

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

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

csiph-web