Linux reports memfd_create() being called without MFD_EXEC or MFD_NOEXEC_SEAL set

[Kerin Millar]

Hi,

At some point after upgrading to bash-5.3-alpha, the following message appeared 
in my kernel ring buffer.

[700406.870502] bash[3089019]: memfd_create() called without MFD_EXEC or 
MFD_NOEXEC_SEAL set

Unfortunately, it took me a while to notice the presence of this message. 
Therefore, I am uncertain as to what bash was being tasked with at the time 
that it was logged. The inference of the message seems clear, however. The 
presently running kernel is 6.6.28.

-- 
Kerin Millar

Re: Linux reports memfd_create() being called without MFD_EXEC or MFD_NOEXEC_SEAL set

[Andreas Schwab]

On Apr 27 2024, Kerin Millar wrote:

> At some point after upgrading to bash-5.3-alpha, the following message 
> appeared in my kernel ring buffer.
>
> [700406.870502] bash[3089019]: memfd_create() called without MFD_EXEC or 
> MFD_NOEXEC_SEAL set

This warning has been tuned down in later kernels, but nevertheless,
bash should pass MFD_NOEXEC_SEAL (if defined) when it calls
memfd_create.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Linux reports memfd_create() being called without MFD_EXEC or MFD_NOEXEC_SEAL set

[Kerin Millar]

On Sat, 27 Apr 2024 14:09:29 +0200
Andreas Schwab  wrote:

> On Apr 27 2024, Kerin Millar wrote:
> 
> > At some point after upgrading to bash-5.3-alpha, the following message 
> > appeared in my kernel ring buffer.
> >
> > [700406.870502] bash[3089019]: memfd_create() called without MFD_EXEC or 
> > MFD_NOEXEC_SEAL set
> 
> This warning has been tuned down in later kernels, but nevertheless,
> bash should pass MFD_NOEXEC_SEAL (if defined) when it calls
> memfd_create.

Thanks. For now, I have applied the attached modification to my working copy.

-- 
Kerin Millar


noexec-seal.patch
Description: Binary data

Re: Examples of concurrent coproc usage?

[Carl Edquist]

On Mon, 22 Apr 2024, Chet Ramey wrote:

You might be surprised. The OP was sending thousands of calculations to 
(I think) GNU bc, which had some resource consumption issue that 
resulted in it eventually hanging, unresponsive. The kill was the 
solution there. I imagine there are similar scenarios with other tools.


Ok, you got me!  I take it back.

I hadn't considered bc operations being cpu/memory intensive.  But that 
possibility makes sense - given that it's arbitrary precision I guess you 
can ask for a number to the billionth power and never see the end of it  :)


Carl

Re: Examples of concurrent coproc usage?

[Carl Edquist via Bug reports for the GNU Bourne Again SHell]

On Mon, 22 Apr 2024, Martin D Kealey wrote:


On Mon, 22 Apr 2024, 09:17 Carl Edquist,  wrote:

[…] I was saying the shell is crippled when limited to builtins; eg, a 
read/printf loop compared to simply running cat.


I would hope that mapfile/readarray could do better, since it's not 
obligated to leave anything in the input stream.


That is an interesting thought, although mapfile seems to read a byte at a 
time also.


[I'm not suggesting this should be changed though.  And frankly I have no 
strong desire for a faster 'read' builtin in the shell, either.  A byte at 
a time is relatively slow, but that's generally fine in most limited 
contexts where it's actually needed.]



But yeah currently a pipe with a series of records and multiple 
cooperating/competing readers perhaps only works if the records have a 
fixed size. A new readd[elim] system call like you're talking about 
would allow safely reading a single variable-length record at a time.


There are other options, such as length-prefixed records, or tagged 
(typed) records, but of course those aren't POSIX text files.


That'd work for "cooperating" readers (as you put it) where they are not 
attempting to read at the same time.  Though reading a single byte at a 
time also works in that case.


My thought is that (performance considerations aside), the real functional 
improvement with a new "readd" call would be with _competing_ readers 
(more than one read call waiting on the same pipe at the same time).


In that case a length-prefixed or type-tagged record wouldn't seem to work 
with the regular read(2), because a single reader would not be able to 
read the length/type _and_ the corresponding record together.  You can't 
work around this by reading a byte at a time either.  That's why I said it 
would only seem to work (with read(2)) if the records have a fixed size. 
(In order to grab a whole record atomically.)


But a new "readd" call would allow multiple competing readers to read, 
say, a stream of filenames from a pipe, without having to pad each one to 
PATH_MAX bytes.


It seems that if there is only one reader at a given time though 
("cooperating"), then it's just a matter of performance between 
read(2)'ing one byte at a time vs using a new readd call.


...

I'm not trying to advocate for or against you contacting the kernel folks 
with your idea; it just seems to me that the scenario with multiple 
competing readers might be the strongest argument for it.



Carl

5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

[Koichi Murase]

I'm currently testing my framework with 5.3-alpha. In 5.3-alpha and
the devel branch, foreground dead jobs are reported by the `jobs'
builtin with function substitutions:

$ bash-5.3-alpha --norc
$ a=${ (true) }; b=${ jobs; }; declare -p b
declare -- b="[1]   Done( true )"

I expect the jobs builtin to exclude the foreground dead jobs in the
above command. This doesn't happen with slightly different versions
like

$ a=${ (true) }; b=${ (jobs); }; declare -p b
$ (true); b=${ jobs; }; declare -p b
$ a=${ (true) }; b=$(jobs); declare -p b
$ a=${ (true) }; jobs
$ a=${ (true) }; (jobs)

I would like to get the list of the background dead jobs using the
`jobs' builtin, but this behavior contaminates it with the foreground
ones as far as I use the function substitutions. If the current
behavior would be the intended one, I would request an option of the
`jobs' builtin that excludes the foreground dead jobs.

--
Koichi

Re: bash: ":?xxx" filename broken on autocomplete

[Gioele Barabucci]

Control: found -1 5.2.21-2

On Tue, 27 Aug 2019 16:36:03 +0200 Philipp Marek  
wrote:
the autocompletion is broken on filenames or directories with ":?" at the 
beginning.


# mkdir ':?aa'
# rmdir :

gives me

# rmdir :\:\?

which doesn't match the filename; I can finish completion by entering "aa", 
but then "rm" rejects this name.


In bash 5.2.21(1) the filename is now fully completed, but the stray ":" 
at the beginning is still produced:


$ mkdir ':?aa'
$ rmdir :
$ rmdir :\:\?aa/

Regards,

--
Gioele Barabucci

5.3-alpha: value substitutions remove unrelated REPLY when its REPLY is removed

[Koichi Murase]

When REPLY that is prepared by a value substitution ${ ; } is
removed by , the value substitution removes the previous-scope
REPLY, which is not prepared by the value substitution, after the
execution of .

$ bash-5.3-alpha --norc
$ unlocal() { unset -v "$@"; }
$ f2() { unlocal "$1"; echo "f2:$1=${!1}"; }
$ f1() { local REPLY=1; a=${| f2 REPLY; }; echo "f1:REPLY=$REPLY"; }
$ f1
f2:REPLY=1
f1:REPLY=

Removing REPLY inside a value substitution is admittedly arguable.
Nevertheless, it is still more consistent for value substitutions to
remove only the REPLY they prepared, if present, and to avoid removing
unrelated REPLY.

--
Koichi

Re: bash: ":?xxx" filename broken on autocomplete

[Kerin Millar]

On Sat, 27 Apr 2024 23:28:49 +0200
Gioele Barabucci  wrote:

> Control: found -1 5.2.21-2
> 
> On Tue, 27 Aug 2019 16:36:03 +0200 Philipp Marek  
> wrote:
> > the autocompletion is broken on filenames or directories with ":?" at the 
> > beginning.
> > 
> > # mkdir ':?aa'
> > # rmdir :
> > 
> > gives me
> > 
> > # rmdir :\:\?
> > 
> > which doesn't match the filename; I can finish completion by entering "aa", 
> > but then "rm" rejects this name.
> 
> In bash 5.2.21(1) the filename is now fully completed, but the stray ":" 
> at the beginning is still produced:
> 
>  $ mkdir ':?aa'
>  $ rmdir :
>  $ rmdir :\:\?aa/

In the course of trying this in bash-5.3-alpha, I noticed something else. If 
':?aa' is not the only entry in the current working directory, readline behaves 
as if : is an ambiguous completion. That is:

# mkdir ':?aa'
# touch 'something-else'
# rmdir :

... produces nothing until pressing the tab key a second time, after which both 
entries are listed while the content of readline's input buffer remains 
unchanged.

-- 
Kerin Millar

Re: bash: ":?xxx" filename broken on autocomplete

[Andreas Schwab]

On Apr 27 2024, Kerin Millar wrote:

> In the course of trying this in bash-5.3-alpha, I noticed something else. If 
> ':?aa' is not the only entry in the current working directory, readline 
> behaves as if : is an ambiguous completion. That is:
>
> # mkdir ':?aa'
> # touch 'something-else'
> # rmdir :
>
> ... produces nothing until pressing the tab key a second time, after which 
> both entries are listed while the content of readline's input buffer remains 
> unchanged.

':' is in $COMP_WORDBREAKS.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: bash: ":?xxx" filename broken on autocomplete

[Kerin Millar]

On Sat, 27 Apr 2024 23:56:28 +0200
Andreas Schwab  wrote:

> On Apr 27 2024, Kerin Millar wrote:
> 
> > In the course of trying this in bash-5.3-alpha, I noticed something else. 
> > If ':?aa' is not the only entry in the current working directory, readline 
> > behaves as if : is an ambiguous completion. That is:
> >
> > # mkdir ':?aa'
> > # touch 'something-else'
> > # rmdir :
> >
> > ... produces nothing until pressing the tab key a second time, after which 
> > both entries are listed while the content of readline's input buffer 
> > remains unchanged.
> 
> ':' is in $COMP_WORDBREAKS.

Ah, I see.

-- 
Kerin Millar

Bug#1069978: bash: incorrect value of $BASH for login shells

[Gioele Barabucci]

Package: bash
Version: 5.2.21-2
X-Debbugs-CC: bug-bash@gnu.org

Hi,

bash 5.0 and 5.2 do not set $BASH to the right value when bash is used 
as the login shell:


$ apt install bash-static
$ getent passwd $USER | cut -d: -f 7
/bin/bash

$ su $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

/usr/bin/bash-static
/usr/bin/bash-static

$ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

/bin/bash
/usr/bin/bash-static

(bash-static is not a link to bash)

Bash also uses the value in /etc/passwd when in login mode, although the 
documentation says


> BASH   Expands to the full filename used to invoke this instance of bash.

"full filename" could be interpreted both as "an absolute filename" as 
well as "the canonical absolute path".


$ su $USER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true'
/usr/bin/bash
/usr/bin/bash

$ su -l $USER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true'
/bin/bash
/usr/bin/bash

Regards,

--
Gioele Barabucci

[bug #65651] argument reference inconsistency

[anonymous]

URL:
  

 Summary: argument reference inconsistency
   Group: The GNU Bourne-Again SHell
   Submitter: None
   Submitted: Sun 28 Apr 2024 06:51:44 AM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Sun 28 Apr 2024 06:51:44 AM UTC By: Anonymous
Try the following script w/ various sets of arguments and tell me if you see
something weird!

#!/bin/bash
echo "script has $# arguments"
echo "cmdline \$* = $*"
echo "first 3 args: [$1] [$2] [$3]"

for a in $*
do
   echo "arg: $a"
done

Argument set:
A)   alpha beta gamma
B)   "alpha" "beta" "gamma"
C)   "alp ha" "be ta" "gam ma"







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/