Default completion bug
Hello,
There is a small bug in the default completion system due to a
disagreement between a few functions in what is considered a command
delimiter. I have tested this on the current devel HEAD in the git repo
(d00a2d6).
Define a default completion:
_completion_loader() {
complete -W "COMPLETE ME" "$1" && return 124
}
complete -F _completion_loader -D
Try to trigger completion for ">" (^I is literal tab):
$ > ^I^I
$ complete -p
complete -F _completion_loader -D
complete -W 'COMPLETE ME' >
Check to make sure things are working:
$ ls ^I^I
COMPLETE ME
$ complete -p
complete -F _completion_loader -D
complete -W 'COMPLETE ME' >
complete -W 'COMPLETE ME' ls
Works just fine for "ls". Now, set a COMPSPEC for the empty string, "":
$ complete -W "EMPTY STRING" ""
And try to complete ">" again:
$ > ^I^I
EMPTY STRING
$ complete -p
complete -W 'EMPTY STRING'
complete -F _completion_loader -D
complete -W 'COMPLETE ME' >
complete -W 'COMPLETE ME' ls
It works this time, but only because it is loading the COMPSPEC for the
empty string, instead of for ">".
The reason for this is that gen_progcomp_completions() first searches
the prog_completes table with the results from find_cmd_name() [1],
which given a command line "> ", returns "" (the empty string).
Failing this, it will call the default completion function
_completion_loader(), and pass it a word list composed from the results
of command_line_to_word_list(), which when given the _same_ command line
"> ", returns the list [">", ""].
Our default completion function then faithfully inserts a COMPSPEC into
prog_completes for the key ">" and returns 124 to restart the completion
loop. However, since the prog_completes table is never looked up with
the key ">", it is never actually found.
Of course, once a COMPSPEC for the empty string is inserted into the
table (which can also be done by trying to complete an empty command
line), completing ">" works as if one was completing the empty string,
which will most likely be assigned the same dynamic completion, thus
having the unfortunate appearance of suddenly working as intended.
I have not attached a patch to this bug report, because I know
the subtle differences of rl_basic_word_break_characters,
COMMAND_SEPARATORS, and the value embedded in find_cmd_name(), are
important, and that any changes, for better or worse, are scrupulously
recorded for ALL TIME. I have implemented a couple of solutions, but who
am _I_ to say what is a command delimiter?
So while a proper fix is complicated, there is a simple workaround
that can be implemented in userland: simply define the completion for
the empty string ("") for the keys that slip between the cracks of the
different command delimiter lists (i.e. "<", ">", ">>"):
complete -o default ""
Cheers,
Sung Pae
[1]: Not directly, but by provenance. These are the stack traces for the
functions progcomp_search() and progcomp_insert():
(HASH SEARCH) (HASH INSERTION)
0 progcomp_search + 39 0 progcomp_insert + 101
1 gen_progcomp_completions + 401 complete_builtin + 943
2 programmable_completions + 115 2 execute_builtin + 500
3 attempt_shell_completion + 1201 3 execute_command_internal + 8420
4 gen_completion_matches + 58 4 execute_command + 138
5 rl_complete_internal + 294 5 execute_command_internal + 16943
6 _rl_dispatch_subseq + 6236 execute_command_internal + 14939
7 readline_internal_char + 267 7 execute_function + 1339
8 readline + 101 8 execute_shell_function + 135
9 yy_readline_get + 1859 gen_compspec_completions + 1107
10 shell_getc + 490 10 gen_progcomp_completions + 149
11 read_token + 525 11 programmable_completions + 261
12 yyparse + 1189 12 attempt_shell_completion + 1201
13 parse_command + 184 13 gen_completion_matches + 58
14 read_command + 200 14 rl_complete_internal + 294
15 reader_loop + 35515 _rl_dispatch_subseq + 623
16 main + 6292 16 readline_internal_char + 267
17 start + 52 17 readline + 101
18 0x0 + 2 18 yy_readline_get + 185
19 shell_getc + 490
20 read_token + 525
21 yyparse + 1189
22 parse_command + 184
23 read_command + 200
24 reader_loop + 355
25 main + 6292
26 start + 52
27 0x0 + 2
Re: Restricted Bash - Not so restrictive (in 4.2 as well)
Hi, Sarnath K - ERS, HCLTech wrote: > I see this problem in the latest Bash 4.2 as well. Say, I invoke > "rbash" or "bash -r". This leaves me in a restrictive shell. > However, this restrictive shell allows me to run "bash" or any other > shell (without execing - just simply run) which leaves me in a > normal shell. Typically rbash is used with a nonstandard PATH setting to give users access to a restricted set of commands. However, I notice that the bash(1) manpage does not mention anything about that. If you can come up with a way to hint at it without making the manpage much longer (maybe by tweaking the sentence that starts "A restricted shell is used to set up an environment"), I imagine that would be helpful. Thanks and hope that helps, Jonathan
Re: Restricted Bash - Not so restrictive (in 4.2 as well)
Sarnath K - ERS, HCLTech wrote: > Apart from this, BASH Documentation says "When a command that is > found to be a shell script is executed (see COMMAND EXECUTION > above), rbash turns off any restrictions in the shell spawned to > execute the script.". > > Does this mean that a guy with restricted shell can just write a > shell script to do a privileged operation and get away with it? "./my-custom-script" contains a "/".
Re: Restricted Bash - Not so restrictive (in 4.2 as well)
On 1/11/12 6:12 AM, Jonathan Nieder wrote: > Hi, > > Sarnath K - ERS, HCLTech wrote: > >> I see this problem in the latest Bash 4.2 as well. Say, I invoke >> "rbash" or "bash -r". This leaves me in a restrictive shell. >> However, this restrictive shell allows me to run "bash" or any other >> shell (without execing - just simply run) which leaves me in a >> normal shell. > > Typically rbash is used with a nonstandard PATH setting to give users > access to a restricted set of commands. The restricted shell is only one of several components of a restricted environment. Two others are a (readonly) value of $PATH that includes only the directory Jonathan mentioned (typically /usr/rbin) and not giving users write access to their home directory. A readonly .profile in a readonly home directory sets up the desired $PATH and leaves the user in some other scratch directory to which he has write access. When I set this kind of thing up about 25 years ago, we used ~/work. It's appropriate for the bash man page to describe the bash behavior when run in restricted mode. That's not the place for a tutorial on how to set up a restricted environment. 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/
Restricted Bash - Not so restrictive (in 4.2 as well)
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF$ uname output: Linux ubuntu 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 05:14:15 UTC 2010 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.1 Patch Level: 5 Release Status: release Description: I see this problem in the latest Bash 4.2 as well. Say, I invoke "rbash" or "bash -r". This leaves me in a restrictive shell. However, this restrictive shell allows me to run "bash" or any other shell (without execing - just simply run) which leaves me in a normal shell. This shell does not have any restricted capabilities. So, the entire purpose of having a restricted shell goes for a toss. I was trying to restrict a user by making "rbash" as his default shell. Now, with this bug, I don't think I can be fool-proof. Repeat-By: sarnath@ubuntu:~$ bash -r To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. sarnath@ubuntu:~$ cd / bash: cd: restricted sarnath@ubuntu:~$ sarnath@ubuntu:~$ bash To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. sarnath@ubuntu:~$ sarnath@ubuntu:~$ cd / sarnath@ubuntu:/$ cd sarnath@ubuntu:~$ Fix: Just my 2 cents. Please apply your discretion: Just make sure that while in restricted mode, the user can spawn only "rbash" and no other shell. Any invocation of "bash" must be replaced with "bash -r". A list of shells/applications could be black-listed in a configuration file which is processed while processing .bashrc This will make bash foolproof. ::DISCLAIMER:: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ---
RE: Restricted Bash - Not so restrictive (in 4.2 as well)
Hello Jonathan, Thanks for the quick hint. What I understand is that you are suggesting me to collate all required commands in a special directory and then use it in the PATH and remove everything else from the PATH in ".bashrc". I think that would really serve my purpose. Thanks! As far as changes to BASH documentation goes, I think the existing documentation is just fine. It clearly says that "A restricted shell is used to setup an environment more controlled than the shell". I think it is up to the administrator to use it innovatively. Apart from this, BASH Documentation says "When a command that is found to be a shell script is executed (see COMMAND EXECUTION above), rbash turns off any restrictions in the shell spawned to execute the script.". Does this mean that a guy with restricted shell can just write a shell script to do a privileged operation and get away with it? Thanks for your time and such a quick response, Best Regards, Sarnath -Original Message- From: Jonathan Nieder [mailto:jrnie...@gmail.com] Sent: Wednesday, January 11, 2012 4:43 PM To: Sarnath K - ERS, HCLTech Cc: bug-bash@gnu.org; b...@packages.debian.org Subject: Re: Restricted Bash - Not so restrictive (in 4.2 as well) Hi, Sarnath K - ERS, HCLTech wrote: > I see this problem in the latest Bash 4.2 as well. Say, I invoke > "rbash" or "bash -r". This leaves me in a restrictive shell. > However, this restrictive shell allows me to run "bash" or any other > shell (without execing - just simply run) which leaves me in a > normal shell. Typically rbash is used with a nonstandard PATH setting to give users access to a restricted set of commands. However, I notice that the bash(1) manpage does not mention anything about that. If you can come up with a way to hint at it without making the manpage much longer (maybe by tweaking the sentence that starts "A restricted shell is used to set up an environment"), I imagine that would be helpful. Thanks and hope that helps, Jonathan ::DISCLAIMER:: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ---
Re: Specify completion without name
Clark J. Wang wrote: On Fri, Jan 6, 2012 at 00:33, Peng Yu wrote: But beware to clearly document these by giving working EXAMPLE code which include these three commands (not just text explanation without working code, by "working code" I mean code snippet is discouraged, a complete completion function should be provided). The bash man page already has ~70 pages manual. I don't like it to grow to ~700 pages (like the ABS Guide) with all the working examples you expected. :) Vs. having things undocumented, as is the case in the current bash man page. I think the bash doc maintainers would benefit greatly by looking at the perl manpages, which generally do a good job of documenting a complex product. Like... compat40 mentions it changes behavior, about interrupting a command list, yet try to find out what that behavior is, or what compat40 would change it 'to'? Or how about, does compat 31 imply compat32 and compat40? If not, does that really mean compat31 is really 'compat31', or just "use 3.1" to specify that a specific feature be used in it's 3.1 version vs. a newer version. I agree insomuch as if every new incompatibility had to be thoroughly documented, the impact of such incompatibilities might be more thoroughly thought out, not to mention the benefit for users trying to read the man page to program by...
Re: Specify completion without name
On 1/11/12 3:03 PM, Linda Walsh wrote: > Like... compat40 mentions it changes behavior, about interrupting a command > list, yet try to find out what that behavior is, or what compat40 would > change it 'to'? Thanks, I added that to the description. It means that bash versions later than 4.0 interrupt a list when one of the commands in the list terminates due to SIGINT and job control is in effect; previous versions just continued on. > > Or how about, does compat 31 imply compat32 and compat40? If not, does that > really mean compat31 is really 'compat31', or just "use 3.1" to > specify that a specific feature be used in it's 3.1 version vs. a newer > version. There is only a single shell compatibility level; the last variable set wins. The compatibility level variables are mutually exclusive. The descriptions of each option are self-contained. That's why the descriptions for compat32 and compat40 include the same text concerning using strcoll for < and > comparisons (and why the description for compat31 should include it as well). The COMPAT file in the bash distribution has a much more extensive description of incompatibilities between versions. 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/
