Re: [PATCH] Support `bind -x' for different keymaps
> Bash Version: 5.0 > Patch Level: 0 > Release Status: release > > Description: > > There are two problems: (1) The keymap `cmd_xmap' used to store the > command strings by `bind -x' is shared with all the keymaps. This > makes problem when one defines `bind -x' key bindings for multiple > different keymaps. (2) `bind -X' dumps all the command strings stored > in `cmd_xmap' including strings which are already unbound. Hello, Are these patches rejected or just forgotten? Best regards, Koichi
Equivalence class in shell pattern does not work
Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-Kt4GMb/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux barinkl 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 2 Release Status: release Description: Equivalence class in shell patterns does not work as expected. On the other hand, equivalence class does work in regular expressions in bash. The problem is in shell patterns inside Extended test [[ ]], globbing and the case compound command. Repeat-By: #It does not work in SP [[ éáö = *[[=e=][=a=][=o=]]* ]]; echo $? 1 [[ éáö == *[[=e=][=a=][=o=]]* ]]; echo $? 1 touch é á ö; echo [[=e=][=a=][=o=]] case éáö in *[[=e=][=a=][=o=]]*) echo ok;; esac #It works in RE as expected: [[ éáö =~ [[=e=][=a=][=o=]] ]]; echo $? 0
[nicolas.io...@m4x.org: Re: Bash 5 change in behavior and SELinux]
I noticed that Bash5 requires some additional permissions that I found
questionable.
Mostly the listing of / and /home
I am wondering whether there is a way to avoid the requirement for above
permissions.
After some digging with the help of the community we came up with the following
analysis:
- Forwarded message from Nicolas Iooss -
Date: Sun, 24 Feb 2019 21:32:13 +0100
From: Nicolas Iooss
To: Dominick Grift
Cc: seli...@vger.kernel.org
Subject: Re: Bash 5 change in behavior and SELinux
On Sun, Feb 24, 2019 at 7:37 PM Dominick Grift
wrote:
>
> On Sun, Feb 24, 2019 at 07:17:33PM +0100, Nicolas Iooss wrote:
> > On Sun, Feb 24, 2019 at 6:39 PM Dominick Grift
> > wrote:
> > >
> > > On Sun, Feb 24, 2019 at 05:59:19PM +0100, Dominick Grift wrote:
> > > > Recently Bash-5 appeared in the Fedora repositories and i instantly
> > > > noticed an inpleasant change (for the record: this did not happen
> > > > before):
> > >
> > > I suppose this is just a "feature" or a "bug" in Bash-5 and that i will
> > > just have to deal with it. Just seems a bit unnecessary access to me.
> > >
> > > >
> > > > [kcinimod@brutus ~]$ touch mytest1.test
> > > > [kcinimod@brutus ~]$ rm ~/*.test
> > > > rm: cannot remove '/home/kcinimod/*.test': No such file or directory
> > > > [kcinimod@brutus ~]$ rm ~/mytest1.test
> > > > [kcinimod@brutus ~]$ echo $?
> > > > 0
> > > >
> > > > After running `semodule -DB` the following AVC denials surfaced:
> > > >
> > > > avc: denied { read } for pid=2178 comm="bash" name="/" dev="dm-3"
> > > > ino=2 scontext=wheel.id:wheel.role:wheel.subj:s0
> > > > tcontext=sys.id:sys.role:files.home.file:s0 tclass=dir permissive=1
> > > > avc: denied { read } for pid=2178 comm="bash" name="/" dev="dm-1"
> > > > ino=2 scontext=wheel.id:wheel.role:wheel.subj:s0
> > > > tcontext=sys.id:sys.role:fs.rootfs.fs:s0 tclass=dir permissive=1
> >
> > [For other readers: these are the labels of /home and /, the parent
> > directories of /home/kcinimod/]
> >
> > > > So I took to #bash and they told me:
> > > >
> > > > 17:43 <_abc_> grift: that is exactly what you see on android and is
> > > > a direct result of the missing x bit equivalent in
> > > > the selinux policy
> > > >
> > > > 17:44 <_abc_> grift: rephrased: globbing the * requires the x bit
> > > > set
> > > > 17:44 <_abc_> (it's equivalent in selinux policy)
> > > >
> > > > So why does this show up as a "read"? Its allowed to "search" "/" and
> > > > "/home", but since Bash 5 this no longer is enough.
> > > >
> > > > Scripts break everywhere because of this
> >
> > What is the syscall associated with the avc entries? This would help
> > finding in bash's source what triggered this behavior.
> > I tried to reproduce your commands in Arch Linux (bash package
> > 5.0.0-1) or Fedora 30 (bash package 5.0.2-1.fc30 for x86_64) by using
> > strace on bash and watching the syscalls, but nothing stood out: I see
> > an "openat(AT_FDCWD, "/home/kcinimod/",
> > O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3" followed by calls to
> > "getdents64(3, ...)", which are like expected. This could be due to
> > several things:
>
> type=SYSCALL msg=audit(02/24/2019 19:33:13.924:18121) : arch=x86_64
> syscall=openat success=yes exit=3 a0=0xff9c a1=0x561168c81e40
> a2=O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC a3=0x0 items=1 ppid=2270
> pid=27900 auid=kcinimod uid=kcinimod gid=kcinimod euid=kcinimod suid=kcinimod
> fsuid=
>
> >
> > * The bash version you are using is not 5.0.2-1.fc30. Which one are you
> > using?
>
> it is 5.0.2-1, downgrading to 4.4.23-7 fixes it
>
> > * It might come from a kernel bug (which would open the parent
> > directories with read access). That would be really strange, but only
> > to be sure: is bash 4 working fine when you downgrade bash package
> > while keeping the same kernel?
>
> Yes 4 is fine
>
> > * Or it might come from a bash dependency (like readline).
>
> Does not look like it: just downgrading "bash" fixes it
I managed to reproduce the issue. Here are the steps I followed:
* Download a Fedora 30 (Rawhide) live CD from
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/
and boot it in a QEMU virtual machine.
* Audit accesses to listing / from the live user: echo '(auditallow
unconfined_t root_t (dir (read)))' > auditallow_custom.cil && semodule
-i auditallow_custom.cil
* Executing "rm ~/*.test" leads to the following log: type=AVC
msg=audit(1551039100.144:488): avc: granted { read } for pid=5225
comm="bash" name="/" dev="dm-0" ino=2
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:object_r:root_t:s0 tclass=dir
* Executing "rm ./*.test" or anything else without the tilde does NOT
produce the AVC.
* Here is a gdb session with an interesting backtrace (once debug
symbols are installed using "sudo dnf debuginfo-install bash glibc"):
$ gdb -q --args bash -c 'rm ~/*.test'
(gdb) catch syscall openat
Catc
Re: [nicolas.io...@m4x.org: Re: Bash 5 change in behavior and SELinux]
Simple test:
21:54 So, the simple testcase, without SELinux : |
21:54 - sudo chmod a-r /home |
21:54 - cd $HOME |
21:54 - touch a.test |
21:54 - rm ~/*.test |
21:54 => rm: cannot remove '/home/liveuser/*.test': No |
such file or directory |
21:54 and a.test is still there
On Sun, Feb 24, 2019 at 09:50:41PM +0100, Dominick Grift wrote:
> I noticed that Bash5 requires some additional permissions that I found
> questionable.
>
> Mostly the listing of / and /home
>
> I am wondering whether there is a way to avoid the requirement for above
> permissions.
>
> After some digging with the help of the community we came up with the
> following analysis:
>
> - Forwarded message from Nicolas Iooss -
>
> Date: Sun, 24 Feb 2019 21:32:13 +0100
> From: Nicolas Iooss
> To: Dominick Grift
> Cc: seli...@vger.kernel.org
> Subject: Re: Bash 5 change in behavior and SELinux
>
> On Sun, Feb 24, 2019 at 7:37 PM Dominick Grift
> wrote:
> >
> > On Sun, Feb 24, 2019 at 07:17:33PM +0100, Nicolas Iooss wrote:
> > > On Sun, Feb 24, 2019 at 6:39 PM Dominick Grift
> > > wrote:
> > > >
> > > > On Sun, Feb 24, 2019 at 05:59:19PM +0100, Dominick Grift wrote:
> > > > > Recently Bash-5 appeared in the Fedora repositories and i instantly
> > > > > noticed an inpleasant change (for the record: this did not happen
> > > > > before):
> > > >
> > > > I suppose this is just a "feature" or a "bug" in Bash-5 and that i will
> > > > just have to deal with it. Just seems a bit unnecessary access to me.
> > > >
> > > > >
> > > > > [kcinimod@brutus ~]$ touch mytest1.test
> > > > > [kcinimod@brutus ~]$ rm ~/*.test
> > > > > rm: cannot remove '/home/kcinimod/*.test': No such file or directory
> > > > > [kcinimod@brutus ~]$ rm ~/mytest1.test
> > > > > [kcinimod@brutus ~]$ echo $?
> > > > > 0
> > > > >
> > > > > After running `semodule -DB` the following AVC denials surfaced:
> > > > >
> > > > > avc: denied { read } for pid=2178 comm="bash" name="/" dev="dm-3"
> > > > > ino=2 scontext=wheel.id:wheel.role:wheel.subj:s0
> > > > > tcontext=sys.id:sys.role:files.home.file:s0 tclass=dir permissive=1
> > > > > avc: denied { read } for pid=2178 comm="bash" name="/" dev="dm-1"
> > > > > ino=2 scontext=wheel.id:wheel.role:wheel.subj:s0
> > > > > tcontext=sys.id:sys.role:fs.rootfs.fs:s0 tclass=dir permissive=1
> > >
> > > [For other readers: these are the labels of /home and /, the parent
> > > directories of /home/kcinimod/]
> > >
> > > > > So I took to #bash and they told me:
> > > > >
> > > > > 17:43 <_abc_> grift: that is exactly what you see on android and is
> > > > > a direct result of the missing x bit equivalent in
> > > > > the selinux policy
> > > > >
> > > > > 17:44 <_abc_> grift: rephrased: globbing the * requires the x bit
> > > > > set
> > > > > 17:44 <_abc_> (it's equivalent in selinux policy)
> > > > >
> > > > > So why does this show up as a "read"? Its allowed to "search" "/" and
> > > > > "/home", but since Bash 5 this no longer is enough.
> > > > >
> > > > > Scripts break everywhere because of this
> > >
> > > What is the syscall associated with the avc entries? This would help
> > > finding in bash's source what triggered this behavior.
> > > I tried to reproduce your commands in Arch Linux (bash package
> > > 5.0.0-1) or Fedora 30 (bash package 5.0.2-1.fc30 for x86_64) by using
> > > strace on bash and watching the syscalls, but nothing stood out: I see
> > > an "openat(AT_FDCWD, "/home/kcinimod/",
> > > O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3" followed by calls to
> > > "getdents64(3, ...)", which are like expected. This could be due to
> > > several things:
> >
> > type=SYSCALL msg=audit(02/24/2019 19:33:13.924:18121) : arch=x86_64
> > syscall=openat success=yes exit=3 a0=0xff9c a1=0x561168c81e40
> > a2=O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC a3=0x0 items=1 ppid=2270
> > pid=27900 auid=kcinimod uid=kcinimod gid=kcinimod euid=kcinimod
> > suid=kcinimod fsuid=
> >
> > >
> > > * The bash version you are using is not 5.0.2-1.fc30. Which one are you
> > > using?
> >
> > it is 5.0.2-1, downgrading to 4.4.23-7 fixes it
> >
> > > * It might come from a kernel bug (which would open the parent
> > > directories with read access). That would be really strange, but only
> > > to be sure: is bash 4 working fine when you downgrade bash package
> > > while keeping the same kernel?
> >
> > Yes 4 is fine
> >
> > > * Or it might come from a bash dependency (like readline).
> >
> > Does not look like it: just downgrading "bash" fixes it
>
> I managed to reproduce the issue. Here are the steps I followed:
> * Download a Fedora 30 (Rawhide) live CD from
> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/
"$@" expansion when it is consists of only null strings
There are some what seem to be regressions (?) in bash-4.4 and
bash-5.0 regarding the handling of "$@" expansion when it consists
entirely of null strings.
The relevant commits are bash-20160722 [1], bash-20170331 [2],
bash-20190220 [3].
Using:
$ n() { echo $#; }
Since bash-20160722:
$ set -- ''
$ n "$@"''
0
$ set -- '' ''
n ''"$@"
1
n "$@"''
1
n ''"$@"''
0
(and, since bash-20190220, also in the ${x+} PE form)
Since bash-20170331:
$ set -- ''
$ n ${_+''"$@"''}
0
$ n ${_+"$@" "$@"}
1
On a related note, with $#=0, bash-20190220 fixed the expansion of
${_"$@"''} and ${''"$@"} to produce a single field but not so with:
$ set --
$ n ${_+''"$@"''}
0
And these have always been the case, but I'm not sure if it should be so?
$ set --
$ n "${_+"$@"}"
1
$ n "${_+$@}"
1
[1]:
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=13eae87b0c5dbc31a7d352ce17c6817bb79b9226
[2]:
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=7c4ef411b5f1a458c2908efe503e075e5a682040
[3]:
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=9e48f856544da2d2cc95600f487e5b5bcefa0d85
Re: [nicolas.io...@m4x.org: Re: Bash 5 change in behavior and SELinux]
On Sun, Feb 24, 2019 at 5:14 PM Dominick Grift wrote: > > Simple test: This seems to be the same as https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00276.html https://lists.gnu.org/archive/html/bug-bash/2019-02/msg0.html Which has been fixed in the devel branch
turning on file+line for functions with shopt -s extdebug gives error
This is oddI wanted to turn on the file+line numbers on the function
defs...thought it might help the debugger as it gets confused when
functions are already in memory, but when I did that, now I get
a weird error on login:
/usr/share/bashdb/init/require.sh: line 17: _Dbg_requires: unbound variable
I looked at the file -- and could work around:
if [[ -z _Dbg_requires ]] ; then
with this:
if [[ -z ${_Dbg_requires:-""} ]] ; then
Even though later in the code it defines it to be a map(hash).
But once I did that, then I got:
/usr/share/bashdb/init/opts.sh: line 100: _Dbg_tmpdir: unbound variable
Am concerned I'll end up chasing a bunch of problems, but
more to the point -- why is it calling the bashdb anyway?
I looked under extdebug effects under shopt and don't see anything
about bashdb being invoked.
I do see something about "function tracing" and "error tracing"
being turned on == but couldn't find either of those words
defined in the rest of the manpage.
I saw that it might try to call a DEBUG trap, and if it didn't
return 0 unexpected things might happen, so made sure to install
a Trap handler with:
trap : DEBUG
which returns 0 all the time.
So why is bashdb being called? Is it going to be updated?
Thanks!
Re: "$@" expansion when it is consists of only null strings
Date:Sun, 24 Feb 2019 18:37:33 -0500
From:Grisha Levit
Message-ID:
| There are some what seem to be regressions (?) in bash-4.4 and
| bash-5.0 regarding the handling of "$@" expansion when it consists
| entirely of null strings.
I think these are actually more the insertion of explicit null
strings, rather than $@ when it contains null strings. These
are essentially the same as the ${b+s ''} issue that was discussed
a week or so ago, and which Chet already said he would look into.
| $ set -- ''
| $ n "$@"''
| 0
Should be 1. It would be if the '' null string was not there.
| $ set -- '' ''
| n ''"$@"
| 1
Should be 2. $1 gets obliterated by the '' and $2 remains.
| n "$@"''
| 1
Same (should be 2) except here $1 remains and $2 is lost.
| n ''"$@"''
| 0
Again, should be 2, here both $1 and $2 are lost.
Of course if you just did
n "$@"
you'd get 2 as you should (no explicit null strings to kill the $@ expansions).
| $ set -- ''
| $ n ${_+''"$@"''}
| 0
Should be 1
| $ n ${_+"$@" "$@"}
| 1
Should be 2. Not sure what is up with that one as there
are no explicit null strings to confuse things. Each $@ should
expand to (quoted) $1 (even though that means ""), which is then
field split at the (unquoted) space to leave 2 null string args.
| On a related note, with $#=0, bash-20190220 fixed the expansion of
| ${_"$@"''} and ${''"$@"} to produce a single field but not so with:
I assume you mean ${_+"$@"''} and ${_+''"$@"} ? But even bash2 got
those correct (they're both 1). bash5 gets the 2nd one wrong (0)
but I might be testing an older version than you meant had fixed it
(I do not build development versions.) BASH_VERSION='5.0.0(1)-release'
| $ set --
| $ n ${_+''"$@"''}
| 0
Should also be 1.
| And these have always been the case, but I'm not sure if it should be so?
|
| $ set --
| $ n "${_+"$@"}"
| 1
| $ n "${_+$@}"
| 1
Those are, I believe, unspecified cases. The first is definitely
because of the strange quoting (the " chare are in order, open, close,
open, close, not open open close close). Anything could replace the
$@ in that (even just x ) and you'd still get unspecified results.
The second because there's no real agreement whether it should produce
0 or 1 (different shells do different things for that one, and there's
no particularly good argument for one or the other, so posix, I believe,
makes that one unspecified as well.)
kre
ps: for a couple of the last of those (before the unspecified ones)
bosh and yash seem to get them wrong as well, both giving 0 for both of
n ${_+''"$@"''} and n ${_+"$@" "$@"} ... but that's because they don't
implement $_ (and good on them for that, stupid thing it is), so the
word after the "+" isn't used unless one does _=X or similar first.
bosh still gets n ${_+"$@" "$@"} wrong though (0), even when _ is set.
