bash 4.4-rc1 EXECIGNORE not fully working?
$ type -a ls ls is /bin/ls $ # ls tab completion includes ls $ ls foo foo $ EXECIGNORE=/bin/ls $ type -a ls bash: type: ls: not found $ # ls tab completion does not include ls $ ls foo foo $ /bin/ls foo foo So ls is still executed despite the setting. I tried the same with /usr/bin/find and got the same result. GNU bash, version 4.4.0(1)-rc1 (x86_64-unknown-linux-gnu) -- Visit serverfault.com to get your system administration questions answered.
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On 3/18/16 1:05 PM, Eric Blake wrote: > Maybe the compromise is calling this report a doc bug, and changing > Chet's wording to nuke the trailing "and command execution", so that it > remains as documented mention that it affects ONLY completion (since > 'type -a' is similar to completion in nature). I think the better fix, and something that makes the name more appropriate, is to fix the code so that it affects all PATH searching and change the documentation to say that it affects PATH searching for command execution. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On 3/18/16 12:09 PM, Dennis Williamson wrote: > $ type -a ls > ls is /bin/ls > $ # ls tab completion includes ls > $ ls foo > foo > $ EXECIGNORE=/bin/ls > $ type -a ls > bash: type: ls: not found > $ # ls tab completion does not include ls > $ ls foo > foo > $ /bin/ls foo > foo > > So ls is still executed despite the setting. I tried the same with > /usr/bin/find and got the same result. Yes, this is my fault. I did not check the original patch carefully enough. It claimed to inhibit executables found via a PATH search, but did not do a complete job. (I also managed to drop the last line from the original patch.) It's an easy one-line fix to make the behavior match the documentation, at least with respect to PATH searching, and that will be in the bash-4.4 release. You should note that it would never have worked given the example above; the first time you executed ls -- before setting EXECIGNORE -- put the full pathname into the hash table and inhibited future path lookups. I need to modify the documentation to clarify that it only affects PATH lookups. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On 03/18/2016 10:09 AM, Dennis Williamson wrote: > $ type -a ls > ls is /bin/ls > $ # ls tab completion includes ls > $ ls foo > foo > $ EXECIGNORE=/bin/ls > $ type -a ls > bash: type: ls: not found > $ # ls tab completion does not include ls > $ ls foo > foo > $ /bin/ls foo > foo > > So ls is still executed despite the setting. I tried the same with > /usr/bin/find and got the same result. What were you expecting to have happen? EXECIGNORE only controls whether a file matching the glob is excluded from tab completions (which it sounds like it did), not whether bash will avoid executing it (and you proved that it is still executable). The main use for EXECIGNORE is for ignoring *.so or *.dll files, which must have executable permissions, but which you do not want polluting tab completion. So, without further details, I don't see any bug here. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On 03/18/2016 11:36 AM, Andreas Schwab wrote: > Eric Blake writes: > >> But I don't know whether bash is calling exec[lv] with a canonicalized >> name instead of exec[lv]p() with the kernel doing the lookup; > > PATH searching is a pure user-space concept. Fine. Then read that as "with libc doing the lookup", since execlvp() is just a libc wrapper around the kernel execve(). The point I was trying to get at was that I don't know if bash does all the PATH lookups itself, or if it delegates; and therefore, I don't know if EXECIGNORE can (or should) affect PATH lookups. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On 03/18/2016 10:35 AM, Greg Wooledge wrote:
> On Fri, Mar 18, 2016 at 10:27:54AM -0600, Eric Blake wrote:
>> What were you expecting to have happen? EXECIGNORE only controls
>> whether a file matching the glob is excluded from tab completions (which
>> it sounds like it did), not whether bash will avoid executing it (and
>> you proved that it is still executable).
>
> The man page says,
>
>EXECIGNORE
> A colon-separated list of shell patterns (see Pattern Matching)
> defining the list of filenames to be ignored by command search.
> Files whose full pathnames match one of these patterns are not
> considered executable files for the purposes of completion and
> command execution.
>
> I believe this agrees more with Dennis's interpretation.
Then we have a documentation bug in my feature submission; Chet changed
the wording I proposed, which was:
https://lists.gnu.org/archive/html/bug-bash/2015-04/msg00130.html
address@hidden EXECIGNORE
+A colon-separated list of extended glob patterns (@pxref{Pattern
+Matching}). Files with full paths matching one of these patterns are
+not considered executable for the purposes of completion and PATH
+searching, but the @code{[}, @code{[[}, and @code{test} builtins are
+not affected. Use this variable to ignore shared library files that
+must have the executable bit set, but which are not actually
+executable.
We've demonstrated that it affects PATH searching insofar that 'type -a'
no longer lists the program, but it does NOT change any exec[lv]p() PATH
searching (if the kernel searches for 'ls', it will find it no matter
what bash has in EXECIGNORE). But I don't know whether bash is calling
exec[lv] with a canonicalized name instead of exec[lv]p() with the
kernel doing the lookup; nor do I have any strong opinions about whether
EXECIGNORE should be able to completely blacklist the execution of a
particular program, so much as only hiding it from tab-completion.
Maybe the compromise is calling this report a doc bug, and changing
Chet's wording to nuke the trailing "and command execution", so that it
remains as documented mention that it affects ONLY completion (since
'type -a' is similar to completion in nature).
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: bash 4.4-rc1 EXECIGNORE not fully working?
Eric Blake writes: > But I don't know whether bash is calling exec[lv] with a canonicalized > name instead of exec[lv]p() with the kernel doing the lookup; PATH searching is a pure user-space concept. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: bash 4.4-rc1 EXECIGNORE not fully working?
> > > Either EXECIGNORE should block execution or type -a should indicate that its argument matches a pattern in EXECIGNORE. I vote for the latter so a user isn't surprised by execution without a means to identify where it came from. I would also prefer another name. If the purpose is to reduce completion clutter, then the variable should be named something more specific like COMPLETIONIGNORE rather than its seemingly more general current name. I vote against blocking execution since it would enable bypassing earlier parts of PATH. For example, in situations where PATH ends in dot, malicious programs in the current directory could be executed in place of their normal counterpart earlier in PATH. -- Visit serverfault.com to get your system administration questions answered.
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On Fri, Mar 18, 2016 at 10:27:54AM -0600, Eric Blake wrote: > What were you expecting to have happen? EXECIGNORE only controls > whether a file matching the glob is excluded from tab completions (which > it sounds like it did), not whether bash will avoid executing it (and > you proved that it is still executable). The man page says, EXECIGNORE A colon-separated list of shell patterns (see Pattern Matching) defining the list of filenames to be ignored by command search. Files whose full pathnames match one of these patterns are not considered executable files for the purposes of completion and command execution. I believe this agrees more with Dennis's interpretation.
