Re: Bad leaks file fd to child processes

[Dale R. Worley]

Greg Wooledge  writes:
> The fact that pvs *complains* about this instead of just ignoring it makes
> it fairly unique.  I don't know why the authors of pvs chose to do this.
> Perhaps they were working around some known or suspected bug in some other
> program that was commonly used as pvs's parent.

I've always assumed that there was some code inside pvdisplay and other
LVM programs that verified that all the fd's opened by the process were
properly closed before it terminated, to give feedback to the
developers.  And I assumed that the fact that pvdisplay (in the older
version) always printed such a message showed that there was such a bug
in its code.  But it's possible it was due to some aspect of my
environment.

Dale

Re: Bad leaks file fd to child processes

[Greg Wooledge]

On Mon, Nov 28, 2022 at 05:00:28PM -0500, Dale R. Worley wrote:
> Alexey via Bug reports for the GNU Bourne Again SHell 
> > Same behavior was in bash 4.4 (as well as now in bash 5.2):
> >
> > # echo $BASH_VERSION
> > 4.4.0(1)-release
> > # exec 66 > # pvs
> > File descriptor 66 (/etc/hosts) leaked on pvs invocation. Parent PID 
> > 1057606: ./bash
> >
> > But we use the fact tat bash doesn't close FD for example to preliminary 
> > open log file for utility that we will `exec' later.
> > Unfortunately bash doesn't provide any fcntl() mechanism to control FD 
> > flags.
> > It'll be great to have  ability to manage CLOEXEC or any other FD flags 
> > from the script.
> 
> Interesting!  I had misunderstood the complaint, which is that the fd
> leaks *from* bash *to* the program being executed (pvs in the example).
> 
> One aspect is that is the specified behavior of bash.

Given the snippet above, if it were in a script, one would assume that
passing the open FD 66 to the child process was the script author's
intent.  This is useful in a few niche cases.  A similar example that
comes to mind is DJB's tcpclient
 which runs a program with
file descriptors 6 and 7 pre-opened.

The fact that pvs *complains* about this instead of just ignoring it makes
it fairly unique.  I don't know why the authors of pvs chose to do this.
Perhaps they were working around some known or suspected bug in some other
program that was commonly used as pvs's parent.

Re: Bad leaks file fd to child processes

[Dale R. Worley]

Alexey via Bug reports for the GNU Bourne Again SHell 
> Same behavior was in bash 4.4 (as well as now in bash 5.2):
>
> # echo $BASH_VERSION
> 4.4.0(1)-release
> # exec 66 # pvs
> File descriptor 66 (/etc/hosts) leaked on pvs invocation. Parent PID 
> 1057606: ./bash
>
> But we use the fact tat bash doesn't close FD for example to preliminary 
> open log file for utility that we will `exec' later.
> Unfortunately bash doesn't provide any fcntl() mechanism to control FD 
> flags.
> It'll be great to have  ability to manage CLOEXEC or any other FD flags 
> from the script.

Interesting!  I had misunderstood the complaint, which is that the fd
leaks *from* bash *to* the program being executed (pvs in the example).

One aspect is that is the specified behavior of bash.

It's fairly straightforward to prevent a particular fd from leaking to a
single command by explicitly closing it in a redirection on the command:

# echo $BASH_VERSION
5.1.0(1)-release
# exec 66

Re: Bad leaks file fd to child processes

[Alexey via Bug reports for the GNU Bourne Again SHell]

On 2022-11-28 14:20, Koichi Murase wrote:

2022年11月28日(月) 19:06 Alexey via Bug reports for the GNU Bourne Again
SHell :
But we use the fact tat bash doesn't close FD for example to 
preliminary

open log file for utility that we will `exec' later.
Unfortunately bash doesn't provide any fcntl() mechanism to control FD
flags.
It'll be great to have  ability to manage CLOEXEC or any other FD 
flags

from the script.


There is a loadable builtin `fdflags' to do that. If the loadable
builtin is installed (e.g. at /usr/lib/bash/fdflags), we can do
something like

enable -f /usr/lib/bash/fdflags fdflags
fdflags -s +cloexec 

--
Koichi


Many thanks for the example.
But, I still have a lot of prod with bash 4.4 (I guess I could build 
fdflags for 4.4 myself)


Regards,
Alexey

Re: Bad leaks file fd to child processes

[Koichi Murase]

2022年11月28日(月) 19:06 Alexey via Bug reports for the GNU Bourne Again
SHell :
> But we use the fact tat bash doesn't close FD for example to preliminary
> open log file for utility that we will `exec' later.
> Unfortunately bash doesn't provide any fcntl() mechanism to control FD
> flags.
> It'll be great to have  ability to manage CLOEXEC or any other FD flags
> from the script.

There is a loadable builtin `fdflags' to do that. If the loadable
builtin is installed (e.g. at /usr/lib/bash/fdflags), we can do
something like

enable -f /usr/lib/bash/fdflags fdflags
fdflags -s +cloexec 

--
Koichi

Re: Bad leaks file fd to child processes

[Alexey via Bug reports for the GNU Bourne Again SHell]

On 2022-11-26 14:05, "凋叶棕" via Bug reports for the GNU Bourne Again 
SHell wrote:

Hello,

I find that the file descriptor leaks when I execute the command pvs
in bash 5.2, The abnormal scenario is similar to the bug which
reported by
http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00026.html

When I execute pvs in the terminal opened through xshell，it’s ok

PV VG  Fmt  Attr PSizePFree
/dev/sda2  euleros lvm2 a--  <126.00g0

But when I execute pvs in the terminal opened through vscode（use
Remote-SHH to connect linux）, the File descriptor was leaked

File descriptor 19 (/dev/ptmx) leaked on pvs invocation. Parent PID
3789: /usr/bin/bash
File descriptor 20 (/dev/ptmx) leaked on pvs invocation. Parent PID
3789: /usr/bin/bash
File descriptor 21 (/dev/ptmx) leaked on pvs invocation. Parent PID
3789: /usr/bin/bash
File descriptor 99
(/root/.vscode-server/bin/899d46d82c4c95423fb7e10e68eba52050e30ba3/vscode-remote-lock.root.899d46d82c4c95423fb7e10e68eba52050e30ba3)
leaked on pvs invocation. Parent PID 3789: /usr/bin/bash
  PV VG  Fmt  Attr PSizePFree
  /dev/sda2  euleros lvm2 a--  <126.00g0

I found that the leaked file descriptor was created in subst.c

/* Pipe the output of executing STRING into the current shell. */
if (pipe(fildes) < 0)
{
sys_error("%s", _("cannot make pipe for command substitution"));
goto error_exit;
}

add it leaked in

if (--bufn <= 0)
{
SET_CLOSE_ON_EXEC(fd);
bufn = zread(fd, buf, sizeof(buf));
if (bufn <= 0)
break;
bufp = buf;
}

I try to add SET_CLOSE_ON_EXEC (fd) before zread, but it doesn't seem 
to work.


Same behavior was in bash 4.4 (as well as now in bash 5.2):

# echo $BASH_VERSION
4.4.0(1)-release
# exec 66File descriptor 66 (/etc/hosts) leaked on pvs invocation. Parent PID 
1057606: ./bash


But we use the fact tat bash doesn't close FD for example to preliminary 
open log file for utility that we will `exec' later.
Unfortunately bash doesn't provide any fcntl() mechanism to control FD 
flags.
It'll be great to have  ability to manage CLOEXEC or any other FD flags 
from the script.


Regards,
Alexey.

Re: Bad leaks file fd to child processes

[Dale R. Worley]

"凋叶棕" via Bug reports for the GNU Bourne Again SHell
 writes:
> I find that the file descriptor leaks when I execute the command pvs
> in bash 5.2, The abnormal scenario is similar to the bug which
> reported by
> http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00026.html 
>  
> When I execute pvs in the terminal opened through xshell，it’s ok 
>  
> PV VG  Fmt  Attr PSizePFree 
> /dev/sda2  euleros lvm2 a--  <126.00g0 

My memory is that older versions of pvs (which were called pvdisplay)
would always report that a descriptor was leaked.  It wasn't clear why
they reported it, since pvdisplay must have been noticing that *it*
wasn't closing the descriptor(s) properly, but since the process
terminated within seconds, the descriptors were closed by process
termination anyway.

This report seems likely to be the same thing, the descriptor leakage is
in the pvs process, and will be cleaned up by process termination.

A simple way to verify whether bash is leaking fd's is:

# # List all the fd's that Bash has open.
# ls -l /proc/$$/fd
total 0
lrwx--. 1 root root 64 Nov 27 22:12 0 -> /dev/pts/2
lrwx--. 1 root root 64 Nov 27 22:12 1 -> /dev/pts/2
lrwx--. 1 root root 64 Nov 27 22:12 2 -> /dev/pts/2
lrwx--. 1 root root 64 Nov 27 22:13 255 -> /dev/pts/2
lr-x--. 1 root root 64 Nov 27 22:12 3 -> /var/lib/sss/mc/passwd
lrwx--. 1 root root 64 Nov 27 22:13 4 -> 'socket:[1390116]'
# # Run some program.
# pvs
  PV VG  Fmt  Attr PSizePFree   
  /dev/sda3  Hobgoblin01 lvm2 a--  <300.00g  <40.00g
  /dev/sda5  Hobgoblin01 lvm2 a--  <630.02g <580.02g
  /dev/sdb3  Hobgoblin01 lvm2 a--<1.82t1.77t
# # Again list all the fd's that Bash has open.
# ls -l /proc/$$/fd
total 0
lrwx--. 1 root root 64 Nov 27 22:12 0 -> /dev/pts/2
lrwx--. 1 root root 64 Nov 27 22:12 1 -> /dev/pts/2
lrwx--. 1 root root 64 Nov 27 22:12 2 -> /dev/pts/2
lrwx--. 1 root root 64 Nov 27 22:13 255 -> /dev/pts/2
lr-x--. 1 root root 64 Nov 27 22:12 3 -> /var/lib/sss/mc/passwd
lrwx--. 1 root root 64 Nov 27 22:13 4 -> 'socket:[1390116]'
#

Dale

Re: Bad leaks file fd to child processes

[Chet Ramey]

On 11/26/22 5:05 AM, 凋叶棕 via Bug reports for the GNU Bourne Again SHell 
wrote:

Hello,
  
I find that the file descriptor leaks when I execute the command pvs in bash 5.2, The abnormal scenario is similar to the bug which reported by http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00026.html


Can you supply a reproducer that demonstrates this is a problem with bash?

--
``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: Bad leaks file fd to child processes

[Andreas Schwab]

On Nov 26 2022, "凋叶棕" via Bug reports for the GNU Bourne Again SHell wrote:

> But when I execute pvs in the terminal opened through vscode（use Remote-SHH 
> to connect linux）, the File descriptor was leaked 
>  
> File descriptor 19 (/dev/ptmx) leaked on pvs invocation. Parent PID 3789: 
> /usr/bin/bash 
> File descriptor 20 (/dev/ptmx) leaked on pvs invocation. Parent PID 3789: 
> /usr/bin/bash 
> File descriptor 21 (/dev/ptmx) leaked on pvs invocation. Parent PID 3789: 
> /usr/bin/bash 
> File descriptor 99 
> (/root/.vscode-server/bin/899d46d82c4c95423fb7e10e68eba52050e30ba3/vscode-remote-lock.root.899d46d82c4c95423fb7e10e68eba52050e30ba3)
>  leaked on pvs invocation. Parent PID 3789: /usr/bin/bash 

That looks more like the FD leak is in vscode (and bash just hands them
through).

-- 
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."

Bad leaks file fd to child processes

[??????]

Hello, 
 
I find that the file descriptor leaks when I execute the command pvs in bash 
5.2, The abnormal scenario is similar to the bug which reported by 
http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00026.html 
 
When I execute pvs in the terminal opened through xshell??it??s ok 
 
PV VG  Fmt  Attr PSizePFree 
/dev/sda2  euleros lvm2 a--  <126.00g0 
 
But when I execute pvs in the terminal opened through vscode??use Remote-SHH to 
connect linux??, the File descriptor was leaked 
 
File descriptor 19 (/dev/ptmx) leaked on pvs invocation. Parent PID 3789: 
/usr/bin/bash 
File descriptor 20 (/dev/ptmx) leaked on pvs invocation. Parent PID 3789: 
/usr/bin/bash 
File descriptor 21 (/dev/ptmx) leaked on pvs invocation. Parent PID 3789: 
/usr/bin/bash 
File descriptor 99 
(/root/.vscode-server/bin/899d46d82c4c95423fb7e10e68eba52050e30ba3/vscode-remote-lock.root.899d46d82c4c95423fb7e10e68eba52050e30ba3)
 leaked on pvs invocation. Parent PID 3789: /usr/bin/bash 
  PV VG  Fmt  Attr PSizePFree 
  /dev/sda2  euleros lvm2 a--  <126.00g0 
 
I found that the leaked file descriptor was created in subst.c 
 
/* Pipe the output of executing STRING into the current shell. */ 
if (pipe(fildes) < 0) 
{ 
sys_error("%s", _("cannot make pipe for command substitution")); 
goto error_exit; 
} 
 
add it leaked in  
 
if (--bufn <= 0) 
{ 
SET_CLOSE_ON_EXEC(fd); 
bufn = zread(fd, buf, sizeof(buf)); 
if (bufn <= 0) 
break; 
bufp = buf; 
} 
 
I try to add SET_CLOSE_ON_EXEC (fd) before zread, but it doesn't seem to work.