From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23426 invoked by alias); 2 Sep 2016 15:08:23 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39159 Received: (qmail 3685 invoked from network); 2 Sep 2016 15:08:23 -0000 X-Qmail-Scanner-Diagnostics: from nm1-vm6.bullet.mail.ir2.yahoo.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(212.82.96.77):SA:0(0.0/5.0):. Processed in 0.553845 secs); 02 Sep 2016 15:08:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,SPF_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: okiddle@yahoo.co.uk X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.mail.yahoo.com designates 212.82.96.77 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1472828530; bh=R/YOi4oeDK/5jESFoJqZDXp2iI5jxU/8QqurjkayS1k=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=SiMlWwv4T/lZPeHDFJIhPKcwckZBdYAKe7NKKPeTIZ3gWNa8lP8fhFFht2D4bx0h9O1JR75YQdATUCbkv5b12dB7ARD2AHxcPYCAL1SwG3kltBYbaxvwT+knKKqavDlaet3T3pJI0FGA/4qwRR8RhRp6aE9UmkKBpChUEgDjPnF66TMU27xY6y6HJeMnR3UqDUoDkjTIfEYRgqimR757dJSf/a2wgDdapKjTOu88xWpdXoXUY0fPBFYsoCdFPPPve79NM1wWYuVS5nDYk10QfFvlhZgYplAgKLC8h1SHL3E2emD+1pQ+bykWTUCOB3T1zexQ479CMNK+fyQDNXkd1g== X-Yahoo-Newman-Id: 559824.55474.bm@smtp130.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BcU1eY4VM1lPNwBbImlGrK0bZiU5eUMWNz3BqqJGko9a3Hn kx8JmOJjFh.8DciAxXpx.hLXsszPn3cN7DUKfDPk8CWm4RmFKUqvzH.0BCvE Y2mkAsoONlhLl37DmaAv_Nqo2BgMRnJx0ZEk5uFHS3IPCROq2FHZL.JUMA4w tA8azac.r_PGqYpp5DtlN5d2o4yjUg0da2GECJ5_g8zW6iIJqqav_FIry51B EDFQGco69.oDJp01FwBAbJKem_slXTO6I4XZ.zxWuJcaYHoIVMM.YSLKEPwT WGvreMNx2MjMvIxDQ.fW4XyCT3PeWSbuAxl5.W6DnWihzwlqpokicbVWJnWW f8ja2LrKgF6H4jS5fDmHlT2Usc268gHoEgj8gi20teVuFp68Kkp40ZMcMjPq DP4AjC3lyexKcLXGv3GCHRX.IxFl2v8QQ4a.yG5RbFfTj8c9rPn1A0oZq8yS Ta1DWvOI0lZJpIzLBEzCqOe97bVMjwTDJKqkAyG_6HdQN4gfm8SemUoR.Nj8 ebqnHimUr9CyqdgZLs1T544Qc70DjUqr0Deq.MHFqby4- X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- In-reply-to: <20160902052342.GA8514@fujitsu.shahaf.local2> From: Oliver Kiddle References: <8eb6dce0-50d7-5ab2-503a-194c1de2e45d@redhat.com> <20160713045957.GA3893@tarsus.local2> <9968da53-c1fd-fa2a-f30c-c74f884d2478@redhat.com> <20160720065832.GA28939@tarsus.local2> <699166a0-b0f0-452c-2561-b7e3cc952062@redhat.com> <25001.1469117569@hydra.kiddle.eu> <20160722071927.GG2521@tarsus.local2> <12554.1472678120@hydra.kiddle.eu> <20160902052342.GA8514@fujitsu.shahaf.local2> To: zsh-workers@zsh.org Subject: Re: [PATCH] _virsh (Was: Re: zsh virsh completion) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <66036.1472828529.1@hydra.kiddle.eu> Content-Transfer-Encoding: 8bit Date: Fri, 02 Sep 2016 17:02:09 +0200 Message-ID: <66037.1472828529@hydra.kiddle.eu> Daniel Shahaf wrote: > However, your patch seems to implement something slightly different: the > patch executes sudo when (-p was passed, and) 'gain-privs' is either > unset or set to true, whereas the above paragraphs seem to be arguing > for *not* using sudo when the style is unset? Perhaps I misunderstood > your argument. The code is what I intended. It also requires sudo to be present on the command-line being typed so it seemed reasonable. And it is consistent with the remote-access style. I don't have a strong opinion either, however. It was the unconditionally hard-coded sudo that I did have a strong opinion on. > Executing a command as sudo upon pressing could have undesired > results in two ways: if the user _has_ sudo, executing the command with > sudo could surprise her; and if user _doesn't_ have sudo, executing the > command might result in an email from sudo to the root user. If a user does: sudo virsh start --domain then yes, it might send off a mail to root but they'd get that anyway when they actually try to run the command they're composing. > I see: the privileges gained need not be privileges on the local system. Or it might be something else like switch to the httpd user to run the command. > > It'd perhaps be useful if > > the -p option to _call_program also caused it to add something to > > $curcontext when looking up the command style but I'm not sure where > > that could be done as we already have the tag and argument fields > > filled. Any ideas? > > I suppose it fits best in the "command" part of the context, e.g., > could look up :completion::complete:f-under-sudo::lipsum or so. Perhaps f/sudo? / can't appear in the command name. > Come to think of it, sudoers(5) allows per-command defaults, so if the > completion of the command 'foo' invokes «_call_program -b bar», the > sudoers(5) Defaults!foo clauses wouldn't fire. Hopefully that will do > nothing worse than failing to find completion. At worst, the command will be blocked with a root e-mail. User will need to set the command or gain-privileges style. I also wonder if the prefix perhaps has other uses. With env for instance. > Could we please not introduce any more short opaque names? "priv" is > ambiguous/unclear. Perhaps _comp_gain_privs_prefix. (Or perhaps the > style name should be "gain-privileges".) _comp_gain_privs_prefix starts getting a bit long. And is less user-visible. I'm happy with gain-privileges on the style. > > + '*::arguments:{ _comp_priv_prefix=( $words[1] -n ${(kv)opt_args[(I)(-u|--user)]} ) ; _normal }' > You removed the space that followed the last colon; wouldn't that cause The { … } form is a specifically handled form by _arguments and it won't insert any arguments. So I think this should be fine. The patch below is just documentation. I felt that _comp_priv_prefix itself ought to be documented but there wasn't an obvious place to put it. I could try to squeeze it in under gain-privileges but is there any thoughts on adding a section on standard variables as follows? Zsh convention would probably be to use "parameters" instead of "variables" and I'll do that if anyone objects but we might be doing our user's a favour by ditching that particular convention. I also inserted the otherwise undocumented _comp_caller_options into that new section. Any thoughts on what else might go there? curcontext, _compskip and service are covered elsewhere but it might be clearer to reorganise them into this section. I also moved the comppostfuncs documentation to this section. Does that seem reasonable? > Should $_comp_priv_prefix be left unset when (( ${+funcstack[(r)_ssh]} ))? Yes. Very good point. And as a note to myself, I shouldn't have sudo put any command substitutions into _comp_priv_prefix. Oliver diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo index 9e49913..dab73ef 100644 --- a/Doc/Zsh/compsys.yo +++ b/Doc/Zsh/compsys.yo @@ -1815,6 +1815,14 @@ In the case of the tt(_match) completer, the style may also be set to the string `tt(pattern)'. Then the pattern on the line is left unchanged if it does not match unambiguously. ) +kindex(gain-privileges, completion style) +item(tt(gain-privileges))( +If set to tt(false), certain commands will be prevented from making +use of commands like tt(sudo) or tt(doas) to gain extra privileges when +retrieving information for completion. By default, this would only be +done when a command such as tt(sudo) appears on the command-line. To +force the use of, e.g. tt(sudo), the tt(command) style can be used. +) kindex(keep-prefix, completion style) item(tt(keep-prefix))( This style is used by the tt(_expand) completer. If it is `true', the @@ -3400,12 +3408,6 @@ generating matches all follow the convention of returning status zero if they generated completions and non-zero if no matching completions could be added. -Two more features are offered by the tt(_main_complete) function. The -arrays tt(compprefuncs) and tt(comppostfuncs) may contain -names of functions that are to be called immediately before or after -completion has been tried. A function will only be called once unless -it explicitly reinserts itself into the array. - startitem() findex(_all_labels) item(tt(_all_labels) [ tt(-x) ] [ tt(-12VJ) ] var(tag) var(name) var(descr) [ var(command) var(args) ... ])( @@ -4012,7 +4014,7 @@ The return status of tt(_call_function) itself is zero if the function var(name) exists and was called and non-zero otherwise. ) findex(_call_program) -item(tt(_call_program) var(tag) var(string) ...)( +item(tt(_call_program) [ tt(-p) ] var(tag) var(string) ...)( This function provides a mechanism for the user to override the use of an external command. It looks up the tt(command) style with the supplied var(tag). If the style is set, its value is used as the command to @@ -4020,6 +4022,13 @@ execute. The var(string)s from the call to tt(_call_program), or from the style if set, are concatenated with spaces between them and the resulting string is evaluated. The return status is the return status of the command called. + +If the option `tt(-p)' is supplied it indicates that the command output +is influenced by the permissions it is run with. Unless disabled with +the tt(gain-privileges) style or overidden with the tt(command) style, +tt(_call_program) will make use of commands such as tt(sudo) if +present on the command-line, to match the permissions to whatever the +final command is likely to run under. ) findex(_combination) item(tt(_combination) [ tt(-s) var(pattern) ] var(tag) var(style) var(spec) ... var(field) var(opts) ...)( @@ -4875,7 +4884,38 @@ the same meaning as for tt(_description). ) enditem() -texinode(Completion Directories)()(Completion Functions)(Completion System) +texinode(Completion System Variables)(Completion Directories)(Completion Functions)(Completion System) +sect(Completion System Variables) +cindex(completion system, variables) + +There are some standard variables, initialised by the tt(_main_complete) +function and then used from other functions. + +The standard variables are: + +startitem() +item(tt(_comp_caller_options))( +The completion system uses tt(setopt) to set a number of options. This +allows functions to be written without concern for compatibility with +every possible combination of user options. However, sometimes completion +needs to know what the user's option preferences are. These are saved +in the tt(_comp_caller_options) associative array. +) + +item(tt(_comp_priv_prefix))( +Completion functions such as tt(_sudo) can set the tt(_comp_priv_prefix) +array to a command that may then be used by tt(_call_program) to +match the permissions when calling programs to generate matches. +) +enditem() + +Two more features are offered by the tt(_main_complete) function. The +arrays tt(compprefuncs) and tt(comppostfuncs) may contain +names of functions that are to be called immediately before or after +completion has been tried. A function will only be called once unless +it explicitly reinserts itself into the array. + +texinode(Completion Directories)()(Completion System Variables)(Completion System) sect(Completion Directories) cindex(completion system, directory structure)