Dear Debian folks,


running `sudo aptitude update` and `sudo aptitude safe-upgrade` the
package `lvm2` was updated.

        [UPGRADE] lvm2 2.02.84-3.1 -> 2.02.86-1

During that update the following messages where shown in the terminal
window.

        […]
        Setting up lvm2 (2.02.86-1) ...
        Installing new version of config file /etc/lvm/lvm.conf ...
        Setting up LVM Volume GroupsFile descriptor 60 (/var/log/apt/history.log) leaked on vgscan invocation. Parent PID 31291: /bin/sh
          Reading all physical volumes.  This may take a while...
          Found volume group "vol_storage" using metadata type lvm2
        File descriptor 60 (/var/log/apt/history.log) leaked on vgchange invocation. Parent PID 31291: /bin/sh
          8 logical volume(s) in volume group "vol_storage" now active
        […]

This message only showed up once after `Setting up lvm2 (2.02.86.-1)`
but I am a bit confused what it has to do with
`/var/log/apt/history.log`. In any way, I think no such leakage should
happen.


Thanks,

Paul

Dear Maintainer,

Today, after some time of not seeing this message, when invoking
update-grub I was bothered once again by no less than 135 instances
of this particularly obnoxious message, complaining about a perfectly valid
condition that may occur as part of regular unix and shell programming
practise, and that is impossible to avoid in general except by writing an
lvm wrapper that preemptively closes all 'other' file descriptors.

I did some research, and it appears that the lvm authors have a wish
to bother their end-users with this warning as it *might* be a symptom
of a *possible* bug in *another* program, or a *possible* security issue
in *another* program, which they feel responsible to inform (bother) all
of their users about, who often can't do anything about it anyway.

Their actual justification seems to be: 'once, we were unjustly and
unfairly accused of having a bug in lvm, so we added this message to
prove our innocence, and therefore we want to leave it in'.
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138#15)

I also found out that this particular bug is being reported and complained
about consistently and repeatedly. For debian, I have found the following
duplicates of this bug (dated 2010, 2008, 2007):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581339
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432986 (merged with 466138)
I also found:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/591823

Needless to say I was about to report another instance of this bug...

IMHO, there are several ways to 'solve' this issue outside of lvm:
- adapt the kernel to close all fds>2 on exec
  this would break one of the foundations of unix process semantics.
- adapt the shell(s) and all other programs that might invoke lvm to
  close all fds>2 upon exec (incuding any fds that might have been
  inherited from parent processes)
  This would certainly break a lot of software and shell scripts that
  depend on this feature.
- pollute the system's and everybody's enviroment namespace with the
  environment variable LVM_SUPPRESS_FD_WARNINGS.
- adapt the shell and other programs to specifically test for lvm, and
  close all fds>2 upon exec-ing it.
- Write a wrapper around lvm, that closes all fds>2 before exec-ing lvm,
  or that sets LVM_SUPPRESS_FD_WARNINGS.

Wrt the third option: having unnecessary environment variables is
not only undesirable, it's a maintenance headache, and security
sensitive applications normally do their best to precisely control the
state of the environment, and that does not include random undocumented
variables needed to prevent random software from emitting spurious
messages.

The last two solutions are in fact another way of stating 'lvm is
broken, but we don't get to fix it, so we implemented a workaround'

I don't know if I have ignored an important consideration so far, that
might shed a different light upon the case. If I haven't, and assuming the
upstream authors are unwilling to fix this, please consider at least
patching the debian version to remove the message and silence the bug
reports and the application itself.

If you intend not to fix this issue, please consider adding a message to
one or all of the bug reports stating so, so that users know they don't
need to bother inquiring or adding to the discussion.

Kind regards,

Rogier.