pt in
`ps`.
By default a subshell has the same name as the parent shell.
So when I run `ps/pgrep`, I often get processes with the same name, and
I'd have to parse the output of `pstree` to find out which is which.
And running exec -a "${BASH_ARGV0}_child" while true ; do sleep 1 ; do
On Fri, Sep 06, 2024 at 08:37:54AM +0800, Lockywolf wrote:
> >I think this is appropriate for a loadable builtin. This one is Linux-
> >specific.
>
> I am not experienced enough to have an opinion on whether a loadable
> built-in is better than a feature of "exec&
and
I'd have to parse the output of `pstree` to find out which is which.
And running exec -a "${BASH_ARGV0}_child" while true ; do sleep 1 ; done &
is not a valid syntax.
I think this would greatly simplify debugging shell scripts, but maybe
it's just me.
>I think th
On 9/4/24 5:54 PM, Emanuele Torre wrote:
Not super relevant, but I have a bash loadable builtin that can set the
script's proctitle that I wrote for fun ~1 year ago.
I think this is appropriate for a loadable builtin. This one is Linux-
specific.
--
``The lyf so short, the craft so long to le
I think your idea of using exec -a '' with no positional arguments to
set it is pretty cool, since exec -a changes the argv[0] of the
invoked process and exec with redirections an no arguments applies
redirections to the current shell permanently!
Not super relevant, but I h
On 8/31/24 10:43 PM, Lockywolf wrote:
Dear Bash developers,
May I ask for a small feature to be added to bash?
At the moment exec changes IO redirections for the newly started
processes, but if there is no command for exec'ing, it changes those
redirections for the bash process itself.
On Sun, 1 Sept 2024 at 12:43, Lockywolf <
for_bug-bash_gnu.org_2024-09...@lockywolf.net> wrote:
> Dear Bash developers,
>
> May I ask for a small feature to be added to bash?
>
> At the moment exec changes IO redirections for the newly started
> processes, but if there is
Dear Bash developers,
May I ask for a small feature to be added to bash?
At the moment exec changes IO redirections for the newly started
processes, but if there is no command for exec'ing, it changes those
redirections for the bash process itself.
The exec -a, however, allows settin
The comment describing why this wasn't done has been there since the
start of the repo's history and AFAICT it is not accurate anymore, as
shell_execve only calls realloc when it's going to longjmp rather than
return.
Fixes leak in
bash -O execfail -c 'exec /; :'
-
On Sun, Mar 03, 2024 at 10:29:17PM +, Venkat Raman via Bug reports for the
GNU Bourne Again SHell wrote:
> Repeat-By:
> exec 2>&test1 commands freezes the terminal and unable to close the
> fd.
>
> Fix:
> [Is there a sane way to close the fd?]
You&
kube1 6.7.6-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Feb
23 18:27:29 UTC 2024 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.2
Patch Level: 26
Release Status: release
Description:
[Unable to close a file descriptor created using bash exec ]
Repeat-By
On 2/24/24 5:40 AM, Koichi Murase wrote:
Meanwhile, the behavior that `exec 50>2.txt' does not have an effect
does not seem to be the intentional design. It seems to be just a
side effect of the manipulation of the saved fds. In this sense, the
strange behavior I observe is the one t
#!/usr/bin/env bash
enable -f /path/to/lib/bash/fdflags fdflags
exec 50>1.txt
fdflags -s +cloexec 50
exec 50>2.txt
echo hello >&50
ls -l 1.txt 2.txt
The result is
$ ./reduced.sh
-rw-r--r-- 1 murase murase 6 2024-02-24 13:53:01 1.txt
-rw-r--r-- 1 murase mura
EXEC is an intentional design and is not a random side effect of
some other processing. In this sense, the strange behavior you
observe is a design issue.
Meanwhile, the behavior that `exec 50>2.txt' does not have an effect
does not seem to be the intentional design. It seems to be j
en performing a
n<&m redirection.
$ bash -c 'enable fdflags; exec 6= 3.
I don't know why bash wants/needs to copy the CLOEXEC flag when the user
duplicates a file descriptor.
o/
emanuele6
lib/bash/fdflags fdflags
exec 50>1.txt
fdflags -s +cloexec 50
exec 50>2.txt
echo hello >&50
ls -l 1.txt 2.txt
The result is
$ ./reduced.sh
-rw-r--r-- 1 murase murase 6 2024-02-24 13:53:01 1.txt
-rw-r--r-- 1 murase murase 0 2024-02-24 13:53:01 2.txt
I expect that the strin
page would benefit from that caveat about exec. I felt
the need to test that bit myself. "Surely not."
That addresses the aspect of the behavior that people complain about. If
you use `exec', you want the redirections to persist -- that's the purpose
of using redirecti
On 2023-08-23 at 10:34 -0400, Greg Wooledge wrote:
> So... {var}> redirections were introduced in bash 4.1, and
> varredir_close in bash 5.2. That means that in all versions from
> bash 4.1 to 5.1, you will need the separate "exec {fd}>&-" to close
> the temp FD.
On Aug 23 2023, Greg Wooledge wrote:
> Then again... leaving an FD open in a shell script usually won't matter,
> because the script will exit, and that'll just take care of it. The
> only times it actually matters are long-running bash processes -- either
> interactive shells, or some kind of we
On Wed, Aug 23, 2023 at 09:50:36AM -0400, Zachary Santer wrote:
> From the NEWS file [1]:
>
> o. The new `varredir_close' shell option causes bash to automatically close
>file descriptors opened with {var}redirection unless they're arguments to the `exec'
ly just always use, like
lastpipe.
>From the NEWS file [1]:
o. The new `varredir_close' shell option causes bash to automatically close
file descriptors opened with {var}&1 1>&2 2>&$fd {fd}>&-
words
$ ls /dev/fd
0 1 10 2 3
$ exec {fd}>&-
$ ls /dev/fd
0 1
On Tue, Aug 22, 2023, 21:00 Dale R. Worley wrote:
> Is there any way to write a redirection "Redirect the fd whose number is
> in $FOO to file /foo/bar?" OK, you can write 'bash -c "..."' and
>
i think there was a ' duplicate ' directive .. use that
assemble a command string however you want.
On Wed, 23 Aug 2023, 12:20 Greg Wooledge, wrote:
> > echo Hi {X}>/dev/null
> > ls -l "/proc/$$/fd/$X"
>
> That's a really strange example. I wonder what would lead someone to
> write that particular redirection.
Oh I merely wanted to point out that the redirection persists beyond the
echo comm
and.
I gave two answers:
cmd 3>&1 1>&2 2>&3 3>&-
and
cmd {fd}>&1 1>&2 2>&$fd {fd}>&-
As it turns out, the second one does *not* close the temporary file
descriptor, so each time I ran the function while testing, an extra
file descriptor was left open.
But this variant *does* close it:
cmd {fd}>&1 1>&2 2>&$fd
exec {fd}>&-
I find this incredibly confusing.
On Wed, 23 Aug 2023, 05:29 Greg Wooledge, wrote:
> Excuse me now, while I go and close several open FDs in the shell where
> I tested something the other day, which I had no idea were left open.
>
It's even worse than that; try:
echo Hi {X}>/dev/null
ls -l "/proc/$$/fd/$X"
-Martin
>
On Tue, Aug 22, 2023 at 02:59:14PM -0400, Dale R. Worley wrote:
> The "{var}>..." mechanism *assigns* to $var, rather than
> taking its existing value.
... oh. Well, today I learned something.
Excuse me now, while I go and close several open FDs in the shell where
I tested something the other da
On 8/22/23 2:59 PM, Dale R. Worley wrote:
Is there any way to write a redirection "Redirect the fd whose number is
in $FOO to file /foo/bar?" OK, you can write 'bash -c "..."' and
assemble a command string however you want. But is there a direct way
to write it? The "{var}>..." mechanism *assi
Is there any way to write a redirection "Redirect the fd whose number is
in $FOO to file /foo/bar?" OK, you can write 'bash -c "..."' and
assemble a command string however you want. But is there a direct way
to write it? The "{var}>..." mechanism *assigns* to $var, rather than
taking its existin
On Sun, 20 Aug 2023, 14:15 Grisha Levit, wrote:
> [...] it would probably make sense to undo them if the exec fails and the
> shell is not going to exit.
>
Just one question: how?
The sequence of dup2() and close() calls has to occur before the execve()
call. Whilst they could be
On 8/20/23 12:15 AM, Grisha Levit wrote:
exec {foo}>/tmp/foo
exec "${foo}"<&-
Looks like bash doesn't undo redirections if the exec fails -- so the shell
terminates because the redirection closed stdin.
I agree it would probably make sense to un
On 8/19/23 1:37 PM, jleivent wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
Using exec to close a file descriptor in a variable crashes
bash. It doesn't matter how the fd got into the variable, but
the likely usage is with the {va
On Sat, Aug 19, 2023, 16:42 jleivent wrote:
> bash: exec: 10: not found
> But even that shouldn't cause the shell to terminate if the
> target isn't found, so maybe this is two bugs?
>
> Repeat-By:
>
> exec {foo}
On Sat, Aug 19, 2023 at 01:37:31PM -0400, jleivent wrote:
> Repeat-By:
>
> exec {foo}>/tmp/foo
> exec "${foo}"<&-
Remove the quotes and the $ and it should work.
exec {foo}<&-
The way you've got it is essentially:
e
_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
Using exec to close a file descriptor in a variable crashes
bash. It doesn't matter how the fd got into the variable, but
the likely usage is with the {varname} form, as
On Thu, 26 Jan 2023, 09:37 Sergei Trofimovich, wrote:
> To the bug: looks like 'exec -a' does not work for bash scripts, but does
> work for other executables.
>
Be aware that the kernel is responsible for interpreting #! lines, not bash.
The kernel does several steps wh
ke
> Bash, as given by argument zero.
>
> Whenever bash is executed with a script file, it sets $0 to the
> name of that file. It only uses caller-provided values for $0 when
> a script file is not provided.
>
> $ (exec -a foo bash <<<'echo
e string to be executed, if one is present.
Otherwise, it is set to the filename used to invoke
Bash, as given by argument zero.
Whenever bash is executed with a script file, it sets $0 to the
name of that file. It only uses caller-provided values for $0 when
a script file is
AM Sergei Trofimovich wrote:
> Hello bash maintainers! nixpkgs package collection likes to wrap binaies
> and shell scripts to pass extra environment variables via wrappers.
>
> One example is dejagnu's runtest:
>
> $ cat `which runtest` | unnix
> #! /<>/b
Hello bash maintainers! nixpkgs package collection likes to wrap binaies
and shell scripts to pass extra environment variables via wrappers.
One example is dejagnu's runtest:
$ cat `which runtest` | unnix
#! /<>/bash-5.2-p15/bin/bash -e
PATH=...
export PATH
a database of stuff used in scripts, then if exec reset meta'ly
> to none ( undo em maybe .. i have to figure such for my bashlinker
> project too ) and if that fails restore em back
> the same meta db can be used in IPC somehowly.. important feature, i
> bet in 20 - 40 years there
maybe the same way to implent here a fix may do IPC between bashes ?
a meta database of stuff used in scripts, then if exec reset meta'ly
to none ( undo em maybe .. i have to figure such for my bashlinker
project too ) and if that fails restore em back
the same meta db can be used in IPC some
>I'll look at changing that
Thank you. I agree, making traps behave the same after an exec failure as after
any other failed builtin is a better course of action. It will make the trap
facility stronger. execve failures are not that uncommon, and are hard to
predict in advance. execv
On 10/1/21 2:16 PM, Mark March wrote:
Ok, thank you for clarifying. There is nothing in the documentation about this
behavior as far as I can tell. I would suggest adding a line about traps
getting reset after a failed exec to the paragraph on 'execfail'.
I think it will be a c
Ok, thank you for clarifying. There is nothing in the documentation about this
behavior as far as I can tell. I would suggest adding a line about traps
getting reset after a failed exec to the paragraph on 'execfail'.
-Mark
On Friday, October 1, 2021, 07:02:34 AM PDT, Chet Ram
Date:Fri, 1 Oct 2021 09:59:44 -0400
From:Chet Ramey
Message-ID:
| Yes. When the shell runs `exec', it assumes the execed program will overlay
| the shell process. To make that happen transparently, it has to undo things
| it has done: it ends job contro
On 9/30/21 7:24 PM, Mark March wrote:
If execfail is set, a failed exec does not cause a non-interactive shell to
exit, but it seems to reset the EXIT trap:
Yes. When the shell runs `exec', it assumes the execed program will overlay
the shell process. To make that happen transparently, i
>then no more continued code
man bash(1) says the following for the execfail option:
execfail
If set, a non-interactive shell will not exit if it can‐
not execute the file specified as an argument to the
exec buil
> On Fri, Oct 1, 2021, 01:25 Mark March wrote:
>
> > If execfail is set, a failed exec does not cause a non-interactive shell
> > to exit, but it seems to reset the EXIT trap:
It also appears to reset the EXIT trap in an interactive shell.
unicorn:~$ shopt -s execfail
uni
i think its not a bug but normal runtime
as ive understood, exec 'replaces' itself with , then no
more continued code
well error checking could maybe be better
On Fri, Oct 1, 2021, 01:25 Mark March wrote:
> If execfail is set, a failed exec does not cause a non-interactive shell
&
If execfail is set, a failed exec does not cause a non-interactive shell to
exit, but it seems to reset the EXIT trap:
cat <<'EOF' | bash
shopt -s execfail
trap "echo exiting..." EXIT
exec ~/does-not-exist
echo "exec failed in bash-$BASH_VERSION"
exit 1
EOF
hi, well, i mean as first example around exec socat, not socats exec
directive ( which i used for script tho )
but i dont remember the circumstances
it was long ago like a phenomen
lines of code appeared instead of files i think
but i cant recall exactly
it just, i removed exec it worked
On Sat, Mar 13, 2021 at 01:05:32AM +0100, Alex fxmbsw7 Ratchev wrote:
> i have no example to write here as this was past long
Without sample, i'ts hard to represent your case!
> the story was, i was coding a file server daemon, with socat,
Wow!
> and i figured to use exec why not m
thank you sir
theres a misunderstanding tho
with exec i meant i exec socat instead of without exec
i may be able to reproduce it soon as i need to extend my softwares
peace
On Sun, Mar 14, 2021 at 3:37 PM Dale R. Worley wrote:
> > 2021年3月13日(土) 8:06 Alex fxmbsw7 Ratchev :
> >&g
> 2021年3月13日(土) 8:06 Alex fxmbsw7 Ratchev :
>> but using it resulted sometimes output of code of the script in the output
>> of the files
>> removing exec made it work normally as supposed
One possibility is a typo, using "<<" rather than "<".
2021年3月13日(土) 8:06 Alex fxmbsw7 Ratchev :
> but using it resulted sometimes output of code of the script in the output
> of the files
> removing exec made it work normally as supposed
I don't know about `socat', but maybe it's just the file descriptor
collision. One nee
i have no example to write here as this was past long
the story was, i was coding a file server daemon, with socat, and i figured
to use exec why not more exact more efficient
but using it resulted sometimes output of code of the script in the output
of the files
removing exec made it work
On 2/15/19 7:32 PM, Grisha Levit wrote:
> An `exec` that can't execute the supplied command seems to cause the
> status of job control to become reset to the default state:
>
>$ bash -O execfail -mc 'echo $-; exec xxx; echo $-'
> hmBc
>bash: line
An `exec` that can't execute the supplied command seems to cause the
status of job control to become reset to the default state:
$ bash -O execfail -mc 'echo $-; exec xxx; echo $-'
hmBc
bash: line 0: exec: xxx: not found
hBc
$ set +m; echo $-
hiBHs
$ exec xx
Thanks for the reply.
I was lost and it seems eval was what I was looking for. Nice time.
resond, put your response
UNDER the original text, not ABOVE it. This isn't a Microsoft Windows
mailing list.
Second, this is what the exec command is designed to do.
wooledg:~$ help exec
exec: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
Replace the shell with the giv
Same thing in a shell script.
On 28/09/2018, Francis Gathea wrote:
> Hi. Why is this function closing out my session if typed on the terminal?
>
Hi. Why is this function closing out my session if typed on the terminal?
> On Aug 19, 2018, at 8:45 PM, Lars Schneider wrote:
>
>
>> On Aug 19, 2018, at 6:33 PM, Lars Schneider wrote:
>>
>> Hi,
>>
>> consider this script:
>>
>> #!/bin/bash
>> [ "`whoami`" = "root" ] || {
&g
> On Aug 19, 2018, at 6:33 PM, Lars Schneider wrote:
>
> Hi,
>
> consider this script:
>
> #!/bin/bash
> [ "`whoami`" = "root" ] || {
> exec sudo -u root "$0" "$@"
> }
> read -s -p "
Hi,
consider this script:
#!/bin/bash
[ "`whoami`" = "root" ] || {
exec sudo -u root "$0" "$@"
}
read -s -p "enter stuff: " stuff
If I run the script as normal user (not root!) and I abort the "re
Chet Ramey wrote:
On 3/24/18 3:31 PM, L A Walsh wrote:
bash sleep 1
I get:
/usr/bin/sleep: /usr/bin/sleep: cannot execute binary file
???
Isn't it bash that cannot execute the binary file because
it expected a script?
Think about what happens when you run a command like that. Bas
On 3/24/18 3:31 PM, L A Walsh wrote:
> bash sleep 1
>
> I get:
>
> /usr/bin/sleep: /usr/bin/sleep: cannot execute binary file
>
> ???
> Isn't it bash that cannot execute the binary file because
> it expected a script?
Think about what happens when you run a command like that. Bash sees
that it
7;-c', like:
bash sleep 1
I get:
/usr/bin/sleep: /usr/bin/sleep: cannot execute binary file
???
Isn't it bash that cannot execute the binary file because
it expected a script?
Shouldn't bash be to the left of the ':' with some
error on the right, like "cannot exec binary file" or
"expected script file"?
On Sat, Sep 9, 2017 at 5:16 AM, Martijn Dekker wrote:
> The 'time' reserved word seems to be unable to time subshells that run
> 'exec'. Is this intentional? (ksh93, mksh and zsh all do manage this.)
As far as I know, it is intentional. Read this thread which is ab
The 'time' reserved word seems to be unable to time subshells that run
'exec'. Is this intentional? (ksh93, mksh and zsh all do manage this.)
$ time (sleep 1)
real0m1,003s
user0m0,001s
sys 0m0,002s
$ time (exec sleep 1)
$ time (echo hi; exec sleep 1)
hi
$ echo &q
:;}
> trap 'no_op' DEBUG;
> # Any command in a subshell and background
> ( pwd ) &
>
> Is this a bug or issue in BASh itself, or is it simply a limitation of
> using pre-exec functionality?
I will look at this after bash-4.4 is released. If it's a bug with ba
n BASh itself, or is it simply a limitation of
using pre-exec functionality?
Thank you.
s not POSIX, but it's supported by tcsh, bash, zsh, ksh93
and busybox sh at least.
It's not incremented for subshells, only for shell invocations.
Where the behaviour differs is when using "exec".
All of tcsh, bash and zsh (but not ksh93 nor busybox sh)
decrement SHLVL when a
On Mon, Jun 27, 2016 at 08:25:06PM +0300, #pragma wrote:
> Thank you. You are right, it was just confusing to see on the screen of
> Konsole terminal that "bash program was crashed". So bash not doing
> fork() before exec? It looks like a father process crashes. Crash is
>
> Again, what do you expect to happen? You replace the bash process -- it
> goes away. As soon as the man process terminates, your session ends. This
> is what `exec' does.
>
Thank you. You are right, it was just confusing to see on the screen of
Konsole terminal that
On 6/27/16 12:52 PM, #pragma wrote:
> Thank you for the answer. I would agree with you, but there is something
> more.
> If I change command from the first step to this:
>
> user@host:~$ exec man man man
>
> and leave other steps as were before, then bash crashes as well.
Thank you for the answer. I would agree with you, but there is something
more.
If I change command from the first step to this:
user@host:~$ exec man man man
and leave other steps as were before, then bash crashes as well. Also on
tty logins.
Regards, Michael
On 06/27/2016 05:40 PM, Chet Ramey
On 6/26/16 4:55 PM, #pragma wrote:
> Hello!
>
> OS: Kubuntu 14.04
> Bash version: 4.3.11(1)-release (i686-pc-linux-gnu)
>
> How to reproduce a bug:
>
> (1)
> user@host:~$ exec man !!!
What do you expect to happen? You're replacing the bash process wi
Hello!
OS: Kubuntu 14.04
Bash version: 4.3.11(1)-release (i686-pc-linux-gnu)
How to reproduce a bug:
(1)
user@host:~$ exec man !!!
(2) Then, on man execution, press q
(3) On this stage, if bash didn't exited and there is a line on the screen:
--Man-- next: man(1) [ view (r
On 12/15/15 4:53 AM, konsolebox wrote:
> Ok I accept your point. So it's actually about `source` and `bash
> file`, correct? So would this mean every script I `source` would need
> +x bit now? And if it's not about the +x bit and only about `noexec`,
> would stuff I place that I would want to n
On 12/16/15 3:29 PM, John McKown wrote:
> FWIW (not much), I'm going to go with Chet on this. It may be my ignorance
> speaking, but what can I do in a BASH shell script which I cannot do (at
> all) just by entering the commands by hand?
That's where the scope of the proposal makes a difference.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/15 12:32 AM, Mike Frysinger wrote:
> On 13 Dec 2015 17:24, Chet Ramey wrote:
>> On 12/12/15 4:01 PM, Mike Frysinger wrote:
>>> Today, if you have a script that lives on a noexec mount point, the
>>> kernel will reject attempts to run it direct
FWIW (not much), I'm going to go with Chet on this. It may be my ignorance
speaking, but what can I do in a BASH shell script which I cannot do (at
all) just by entering the commands by hand?
On Wed, Dec 16, 2015 at 2:23 PM, Chet Ramey wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/15 12:17 AM, Mike Frysinger wrote:
>
> (1) the examples i already provided do not involve the user at all, and
> include systems where the user has no direct access to the shell.
You didn't really provide any examples. You mentioned Chr
uld source saved
> state.
Ok I accept your point. So it's actually about `source` and `bash
file`, correct? So would this mean every script I `source` would need
+x bit now? And if it's not about the +x bit and only about `noexec`,
would stuff I place that I would want to not exe
hp/whatever to write to a cache file that will be
read by another app.
i recall some router firmwares being attacked in this way -- a remote
bug only permitted the writing of data to common data locations, but
they picked a place where privileged init scripts would source saved
state.
> Also
t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger wrote:
> On 13 Dec 2015 16:50, konsolebox wrote:
>> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
>> > Today, if you have a script that lives on a noexec mount point, the
>> > kernel will reject attempts to run it directly:
>> > $ printf
On 13 Dec 2015 17:24, Chet Ramey wrote:
> On 12/12/15 4:01 PM, Mike Frysinger wrote:
> > Today, if you have a script that lives on a noexec mount point, the
> > kernel will reject attempts to run it directly:
> > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> > $ chmod a+rx /dev/shm/test.
On 13 Dec 2015 12:21, Piotr Grzybowski wrote:
> On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote:
> > On 12 Dec 2015 15:06, Bob Proulx wrote:
> >> It will almost
> >> certainly get in the way of a reasonable use case.
> >
> > can you name a reasonable use case this breaks ?
>
> source /media
On 12 Dec 2015 23:05, Stephane Chazelas wrote:
> 2015-12-12 16:01:26 -0500, Mike Frysinger:
> [...]
> > This is not a perfect solution as it can still be worked around by
> > inlining the code itself:
> > $ bash -c "$(cat /dev/shm/test.sh)"
> > hi
>
> Or
>
> cat /dev/shm/test.sh | bash
right
On 13 Dec 2015 16:50, konsolebox wrote:
> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
> > Today, if you have a script that lives on a noexec mount point, the
> > kernel will reject attempts to run it directly:
> > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> > $ chmod a+rx /d
On 12/12/15 4:01 PM, Mike Frysinger wrote:
> From: Mike Frysinger
>
> Today, if you have a script that lives on a noexec mount point, the
> kernel will reject attempts to run it directly:
> $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> $ chmod a+rx /dev/shm/test.sh
> $ /dev/shm/test.
2015-12-12 17:53:35 -0500, Mike Frysinger:
[...]
> > It will almost
> > certainly get in the way of a reasonable use case.
>
> can you name a reasonable use case this breaks ?
bash << EOF
some code
EOF
here-documents with many shells (including bash) are implemented
as deleted temporary files (t
2015-12-12 16:01:26 -0500, Mike Frysinger:
[...]
> This is not a perfect solution as it can still be worked around by
> inlining the code itself:
> $ bash -c "$(cat /dev/shm/test.sh)"
> hi
Or
cat /dev/shm/test.sh | bash
I think this kind of hardening is better left to things like
selinux/app
hi,
On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote:
> On 12 Dec 2015 15:06, Bob Proulx wrote:
>> It will almost
>> certainly get in the way of a reasonable use case.
>
> can you name a reasonable use case this breaks ?
source /media/noexecmountpoint/sh/functions.sh;
find_all_files_with_e
On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
> From: Mike Frysinger
>
> Today, if you have a script that lives on a noexec mount point, the
> kernel will reject attempts to run it directly:
> $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> $ chmod a+rx /dev/shm/test.sh
> $ /d
On 12 Dec 2015 22:12, John McKown wrote:
> On Sat, Dec 12, 2015 at 3:01 PM, Mike Frysinger wrote:
> > Today, if you have a script that lives on a noexec mount point, the
> > kernel will reject attempts to run it directly:
> > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> > $ chmod a+rx /
On Sat, Dec 12, 2015 at 3:01 PM, Mike Frysinger wrote:
> From: Mike Frysinger
>
> Today, if you have a script that lives on a noexec mount point, the
> kernel will reject attempts to run it directly:
> $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> $ chmod a+rx /dev/shm/test.sh
> $ /
d it's the right place imo: the program that does the
interpreting in the first place (i.e. the shell) should be checking
for the settings where it's going to be loading that interpreted
code.
the reason binary loaders (e.g. ELF ldso's) don't need to do this is
the kernel either
Mike Frysinger wrote:
> But bash itself has no problem running this file:
> $ bash /dev/shm/test.sh
> hi
>...
> This detracts from the security of the overall system. People
> writing scripts sometimes want to save/restore state (like
> variables) and will restore the content from a noexec poi
1 - 100 of 162 matches
Mail list logo
