SIGSEGV in GNU bash, version 5.1.4(1)-release (sparc-sun-solaris2.10)
Firstly as a minor nit that seems to re-appear yearly there are still
source files in the release tarballs that are not readable to a normal
user :
#
# find . -ls | grep '\-\-\-'
7348095 24 -rw--- 1 286 staff 38962 Jul 8 14:19 ./lib/malloc/malloc.c
73474421 -rw--- 1 286 staff 226 May 29 2020 ./tests/varenv20.sub
#
# chmod 644 ./lib/malloc/malloc.c ./tests/varenv20.sub
Trivial but annoyed as it throws the compile process out the window on
the first initial pass. Otherwise all goes well until we try to use the
resultant bash binary.
I was very surprised to see :
alpha $
alpha $ dbx /opt/bw/bin/bash
node_alpha-host_sun4u-zone_z_003-time_1609232628-pid_10009-uid_16411-gid_20002-fid_bash.core
Reading bash
core file header read successfully
Reading ld.so.1
Reading libreadline.so.8
Reading libhistory.so.8
Reading libcurses.so.2
Reading libintl.so.8.1.7
Reading libiconv.so.2.6.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libdl.so.1
Reading libc.so.1
Reading libc_psr.so.1
Reading en_US.UTF-8.so.3
Reading methods_unicode.so.3
program terminated by signal SEGV (Segmentation Fault)
0x7dbdc658: _kill+0x0008: blu __cerror !
0x7db2f2e4
Current function is termsig_handler
617 kill (getpid (), sig);
(dbx) where
[1] _kill(0x0, 0xb, 0xb, 0x0, 0x0, 0x0), at 0x7dbdc658
=>[2] termsig_handler(sig = 11), line 617 in "sig.c"
[3] termsig_sighandler(sig = 11), line 539 in "sig.c"
[4] __sighndlr(0xb, 0x0, 0x7fffe930, 0x1000d7de0, 0x0, 0xa),
at 0x7dbd8d6c
called from signal handler with signal 11 (SIGSEGV) --
[5] tgetent(0x0, 0x1002af010, 0x116078, 0x0, 0x7ea28000,
0x7ea30528), at 0x7e911fa4
[6] _rl_init_terminal_io(terminal_name = (nil)), line 483 in "terminal.c"
[7] _rl_set_screen_size(rows = 43, cols = 132), line 323 in "terminal.c"
[8] rl_set_screen_size(rows = 43, cols = 132), line 341 in "terminal.c"
[9] get_new_window_size(from_sig = 0, rp = (nil), cp = (nil)), line 90
in "winsize.c"
[10] get_tty_state(), line 2510 in "jobs.c"
[11] initialize_job_control(force = 0), line 4522 in "jobs.c"
[12] shell_initialize(), line 1951 in "shell.c"
[13] main(argc = 1, argv = 0x7618, env =
0x7628), line 572 in "shell.c"
(dbx) regs
current frame: [2]
g0-g10x 0x0025
g2-g30x 0x
g4-g50x0001000d7de0 0xff7f
g6-g70x 0x7e100200
o0-o10x 0x000b
o2-o30x000b 0x
o4-o50x 0x
o6-o70x7fffdc41 0x0001000d8344
l0-l10x000100293d08 0x
l2-l30x 0x
l4-l50x 0x
l6-l70x 0x
i0-i10x000b 0x00010029754c
i2-i30x 0x
i4-i50x 0x
i6-i70x7fffdd21 0x0001000d7ff4
y0x
ccr 0x0044
pc 0x0001000d8344:termsig_handler+0x2c4call kill [PLT]
! 0x100294ce0
npc 0x7dbdc65c:_kill+0xcnop
(dbx)
(dbx) exit
alpha $
This was after a clean compile and all tests from the testsuite passed.
The config.h is attached compressed as :
bash-5.1_004_sunos5.10_sparcv9.002_config.h.xz
The RUNPATH/RPATH and needed dependencies seemed correct :
alpha $ elfdump -delv bash
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_SOLARISei_abiversion: EAV_SUNW_CURRENT
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_EXEC
e_flags:[ EF_SPARCV9_TSO ]
e_entry: 0x1000210e0 e_ehsize: 64 e_shstrndx: 29
e_shoff: 0x3b4a08 e_shentsize: 64 e_shnum: 31
e_phoff: 0x40 e_phentsize: 56 e_phnum: 5
Version Needed Section: .SUNW_version
index fileversion
[2] libsocket.so.1 SUNW_1.1
[3] SUNW_0.7 [ INFO ]
[4] libnsl.so.1 SUNW_0.7
[5] SUNWprivate_1.1
[6] libdl.so.1 SUNW_0.7
[7] libc.so.1 SUNW_1.23
[8] SUNW_1.22.7 [ INFO ]
[9] SUNW_1.22[ INFO ]
[10] SUNW_1.21.2 [ INFO ]
[11] SUNW_1.21[ INFO ]
[12] SUNW_1.18[ INFO ]
[13] SUNW_1.1 [ INFO ]
[14] SUNW_0.9 [ INFO ]
[15]
Re: Checking executability for asynchronous commands
Date:Tue, 29 Dec 2020 10:23:07 -0500 From:Chet Ramey Message-ID: | Bash will save some number of exit statuses corresponding to terminated | asynchronous child processes, and those statuses are retrievable using | `wait'. That number varies -- POSIX says you need to save at least | CHILD_MAX statuses, but bash will look at its nproc resource limit (using | sysconf(3)) and try to save that many, up to a max of 32K in bash-5.1. This | will be sufficient in most cases. The interesting case (for shell authors, in practice this rarely, if ever, actually happens) is how to handle the case where the shell has collected (waited for) the status from a child process, but the script has yet to fetch it (that status is one of those being saved). Then, during that interval it is possible for the same pid to be assigned by the kernel for some other process - and that other process might be a child of the same shell. If that child is a fg process (never moved to bg) there's no real problem, but if it is a bg process, and its pid is exported via $! then there can be a real problem, as the script no longer has any safe documented and simple way to distinguish the two processes (they will have different %n job numbers, but scripts don't usually even consider such things). I have considered have the shell (the one I maintain, not bash) check (both parent and child) after a fork, and abort the child immediately, and simply try the fork again, if the system assigns a pid which would cause a problem like that - but never bothered to actually write the code (both parent and child after the fork can run the same test, in parallel, so there's no issue knowing what happened or what to do next .. the vfork case is similarly easy). It has never been a high priority as, in practice, the issue just doesn't arise. kre
Re: Checking executability for asynchronous commands
On 12/29/20 10:28 AM, Chet Ramey wrote: On 12/28/20 5:30 PM, Eli Schwartz wrote: (Though I have to wonder at these amazing AWOL commands that get uninstalled on people all the time right in the middle of their scripts. It's a potential security concern, though that class of vulnerabilities mostly involves executables being changed between testing and execution. Right, the race condition / security concern is specifically based on the idea that one is checking for permission / authority to run a program, possibly as setuid, and it gets replaced by something malicious before being used. If you were going to blindly run the program either way, then having it be *uninstalled* (i.e. does not exist, period) is... probably not going to result in security concerns. It will just fail to run. And it would do so even without the race condition. By all means, let people be concerned about their commands being replaced by attack code. Not about them being rm'ed. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: Feature Request: stack
On 12/27/20 11:29 PM, William Park wrote: I have feature request: stack variable. Almost like current DIRSTACK with 'pushd' and 'popd', but for regular arrays. I know it can be implemented with array, where you push and pop from the end. But, a real stack is better. How is putting something like this into bash `better' than writing a couple of shell functions to do it? There's no discernable demand, and no use cases. -- ``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/
Re: Checking executability for asynchronous commands
On 12/28/20 5:30 PM, Eli Schwartz wrote: (Though I have to wonder at these amazing AWOL commands that get uninstalled on people all the time right in the middle of their scripts. It's a potential security concern, though that class of vulnerabilities mostly involves executables being changed between testing and execution. -- ``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/
Re: Checking executability for asynchronous commands
On 12/28/20 1:23 AM, Markus Elfring wrote: I got another programming concern: Process identifications are a system resource. The exit status is preserved until this information will eventually be used for corresponding data processing. How many processes can a selected system configuration handle? This is a hard question to answer. It depends on the system, its configuration, the PID allocation rate, and the allocation strategy. PIDs are indeed allocated by the system, using different strategies. Many systems use random allocation through a 16- or 32-bit space (whatever a pid_t is). It's possible to receive the same PID for two different spawned child processes before enumerating the entire PID space. One guarantee is that the system won't reallocate a given PID until it's been reaped, and its parent gets its exit status, so a script will usually have the opportunity to obtain the status information it wants. Bash will save some number of exit statuses corresponding to terminated asynchronous child processes, and those statuses are retrievable using `wait'. That number varies -- POSIX says you need to save at least CHILD_MAX statuses, but bash will look at its nproc resource limit (using sysconf(3)) and try to save that many, up to a max of 32K in bash-5.1. This will be sufficient in most cases. If a script saves exit status information it retrieves using `wait' into shell variables, it can obviously save as many statuses as it wants. So the answer is, as it usually is, "it depends." -- ``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/
Re: Checking executability for asynchronous commands
>…, is not a winning argument. I got further development ideas according to the usage of wait function calls and better error reporting for asynchronous commands. >The OP seems to think that "people will occasionally forget to run `wait`", This happens for various reasons. > and wants to know if we "care" that people will forget … The attention varies for this implementation aspect. > Why should we care? Would you like to care for proper management of system resources (including process identifications)? >The official advice is to run `wait` How do you think about any additional guidance for such a programming interface? Regards, Markus
