Re: bash handles terminate signals incorrectly, when it is run as the init process in a pid namespace
On Sun, Mar 25, 2018 at 11:40 AM, Chet Ramey wrote: > On 3/23/18 4:34 AM, Andrei Vagin wrote: >> On Thu, Mar 22, 2018 at 6:25 PM, Chet Ramey wrote: >>> On 3/22/18 3:38 PM, Andrei Vagin wrote: >>> I am thinking how to fix this issue properly. Here are a few points: * bash should know that signals are ignored if a process is the init process in a pid namespace. >>> >>> Why should it know this? It's not documented, not portable, and conflicts >>> with the way signals are documented to behave. This is a situation-specific >>> problem. >> >> It is "documented" in many places. For exmaple: >> https://lwn.net/Articles/532748/ > > I'm glad you put quotes around "documented" before referring to some > random article. It is not a random article. Its author is Michael Kerrisk, he is a maintainer of Linux Man Pages. And we can forget about these quotes, because actually this behavior is described in the pid_namespaces and kill man pages: http://man7.org/linux/man-pages/man7/pid_namespaces.7.html Only signals for which the "init" process has established a signal handler can be sent to the "init" process by other members of the PID namespace. This restriction applies even to privileged processes, and prevents other members of the PID namespace from accidentally killing the "init" process. http://man7.org/linux/man-pages/man2/kill.2.html The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally. > > * user and kernel signals (SEGV, SIGFPE, SIGBUS, etc) are handled differently >>> >>> Fatal signals (signals whose default disposition is to exit the process) >>> are pretty much handled identically. >> >> Let's I try to elaborate what I mean. > > Bash handles fatal signals identically. I understand that the Linux kernel > changes signal delivery behavior under certain circumstances. > * bash should not return back from termsig_sighandler(), if it has sent a signal to itself. >>> >>> That suggests that the easiest way to solve the problem is to add a call >>> to exit() after the kill(). >> >> You are right with one exception. We expect that the kernel generates >> a core dump file, if a process was killed by SIGSEGV, SIGBUS, SIGFPE, >> etc. >> >> For these signals, we probably can dereference an invalid pointer >> instead of calling exit(). > > If you'd like to submit a patch that does that, I'll take a look. Will do. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
bash shows an error message about unpaired quotes, but they are paired
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-suse-linux-gnu'
-DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0
-grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g
-D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-switch-enum
-Wno-unused-variable -Wno-unused-parameter -Wno-parentheses -ftree-loop-linear
-pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0 -fprofile-use -fprofile-correction
uname output: Linux eiktum 4.15.10-1-default #1 SMP PREEMPT Thu Mar 15 20:31:17
UTC 2018 (5e4329c) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
I have the following text file cowrie:
--- start of cowrie
#!/bin/sh
sudo -u cowrie /srv/cowrie/bin/cowrie stop > /dev/null
sleep 10
# delete small logs (likely irrelevant) and logs older then a week
find /srv/cowrie/log/tty/ -size -1000c -name '*.log' -delete
find /srv/cowrie/log/tty/ -ctime +7 -name '*.log' -delete
sudo -u cowrie /srv/cowrie/bin/cowrie start > /dev/null
--- end of cowrie
I have the following bash script aa.sh:
--- start of aa.sh
#!/bin/bash
run () {
echo "Running: ${*}"
eval ${*}
RET=${?}
if [ ${RET} -ne 0 ] ; then
echo "EXIT CODE NOT ZERO (${RET})!"
fi
return ${RET}
}
cp cowrie cowrietest
run 'sed -i "s/\/etc.*$/systemctl restart cowrie.service/" cowrietest'
run 'sed -i "s/sudo.*cowrie/systemctl/g" cowrietest'
run 'sed -i "s/>.*$/cowrie.service/g" cowrietest'
run 'sed -i "6a\find /srv/cowrie/log/ -mtime +7 -name \'cowrie.*\' -delete"
cowrietest'
--- end of aa.sh
Repeat-By:
If I execute the script I get the following on the terminal:
--- start of output
> ./aa.sh
Running: sed -i "s/\/etc.*$/systemctl restart cowrie.service/" cowrietest
Running: sed -i "s/sudo.*cowrie/systemctl/g" cowrietest
Running: sed -i "s/>.*$/cowrie.service/g" cowrietest
./aa.sh: line 16: unexpected EOF while looking for matching `"'
./aa.sh: line 17: syntax error: unexpected end of file
--- end of output on terminal
Fix:
[fix for the problem, don't include this section.]
Re: bash shows an error message about unpaired quotes, but they are paired
On Mon, Mar 26, 2018 at 1:54 PM, wrote: [...] > run 'sed -i "6a\find /srv/cowrie/log/ -mtime +7 -name \'cowrie.*\' -delete" > cowrietest' That's not how you escape single quotes within single quotes. Read: https://mywiki.wooledge.org/Quotes#Types_of_quoting The proper way would be: run 'sed -i "6a\find /srv/cowrie/log/ -mtime +7 -name '\''cowrie.*'\''...
