Debian Bug report logs - #466138
lvm2: File descriptor 3 left open

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Giorgos D. Pallas" <gpall@ccf.auth.gr>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: lvm2: File descriptor 3 left open

Date: Sat, 16 Feb 2008 21:51:27 +0200

Package: lvm2
Version: 2.02.29-1
Severity: normal

I always get this message, when using any of the lvm2 commands. Two examples:

mordor:/home/gpall# lvdisplay
File descriptor 3 left open
File descriptor 4 left open
  --- Logical volume ---
  LV Name                /dev/evg/root
  VG Name                evg
  LV UUID                ttp166-h21j-D93z-GAfM-8r2s-3C9Q-uSZPla
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                10.00 GB
  Current LE             2560
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:1

  --- Logical volume ---
  LV Name                /dev/evg/myspace
  VG Name                evg
  LV UUID                5XV3cK-EhMS-DE0a-IqWL-W4FA-3b5M-tZG5MH
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                95.32 GB
  Current LE             24402
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:2

mordor:/home/gpall#
mordor:/home/gpall# vgscan
File descriptor 3 left open
File descriptor 4 left open
  Reading all physical volumes.  This may take a while...
  Found volume group "evg" using metadata type lvm2
mordor:/home/gpall#                                        


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lvm2 depends on:
ii  libc6                        2.7-6       GNU C Library: Shared libraries
ii  libdevmapper1.02.1           2:1.02.24-3 The Linux Kernel Device Mapper use
ii  libreadline5                 5.2-3       GNU readline and history libraries

lvm2 recommends no packages.

-- no debconf information

Message #10 received at 466138@bugs.debian.org (full text, mbox, reply):

From: Andras Korn <korn-debbugs@elan.rulez.org>

To: 466138@bugs.debian.org

Subject: Is this LVM message actually useful?

Date: Wed, 8 Jul 2009 13:32:08 +0200

Hi,

as far as I can tell, the "File descriptor x left open" message is just
telling the user about open file descriptors the lvm utility inherited and
successfully closed. The --quiet option doesn't appear to suppress the
message.

Does printing the message serve any useful purpose? I'd expect lvcreate,
lvremove and similar commands to be silent when called with --quiet; only
errors should be printed. How is successfully closing a file descriptor an
error?

Andras

-- 
 Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
                  Smash forehead on keyboard to continue.....

Message #15 received at 466138@bugs.debian.org (full text, mbox, reply):

From: Alasdair G Kergon <agk@redhat.com>

To: Andras Korn <korn-debbugs@elan.rulez.org>

Cc: 466138@bugs.debian.org

Subject: Re: Bug#466138: Is this LVM message actually useful?

Date: Wed, 8 Jul 2009 14:21:05 +0100

On Wed, Jul 08, 2009 at 01:32:08PM +0200, Andras Korn wrote:
> as far as I can tell, the "File descriptor x left open" message is just
> telling the user about open file descriptors the lvm utility inherited and
> successfully closed. 

It's often an indication of a careless programming and can lead to
security problems if a child process inherits access to a rogue file
descriptor and can interfere with it.  The messages were added during a
bug investigation to prove that LVM was not involved.

selinux with a strict policy now also detects this sort of bug.

They can be suppressed by setting the (deliberately-undocumented)
environment variable LVM_SUPPRESS_FD_WARNINGS, but really, the source of
the problem you're seeing should be addressed instead of ignoring the
symptoms.

Alasdair

Message #20 received at 466138@bugs.debian.org (full text, mbox, reply):

From: Andras Korn <korn-debbugs@elan.rulez.org>

To: Alasdair G Kergon <agk@redhat.com>

Cc: 466138@bugs.debian.org

Subject: Re: Bug#466138: Is this LVM message actually useful?

Date: Wed, 8 Jul 2009 16:37:09 +0200

On Wed, Jul 08, 2009 at 02:21:05PM +0100, Alasdair G Kergon wrote:

Hi,

> It's often an indication of a careless programming and can lead to
> security problems if a child process inherits access to a rogue file
> descriptor and can interfere with it.  The messages were added during a
> bug investigation to prove that LVM was not involved.
> 
> selinux with a strict policy now also detects this sort of bug.
> 
> They can be suppressed by setting the (deliberately-undocumented)
> environment variable LVM_SUPPRESS_FD_WARNINGS, but really, the source of
> the problem you're seeing should be addressed instead of ignoring the
> symptoms.

I don't agree; surely, following the above argumentation, each and every
program should go out of its way to close any inherited file descriptor it
didn't expect, and warn the user about them. Incidentally, this would make
chpst -l (which relies on obtaining a lock on a file and then passing this
filedescriptor on to its child, which it execs without a fork) useless.

In my case, I know where the stray FD is coming from: I'm invoking lvm
utilities from a zsh script that has a logging coprocess, and it does an
"exec >&p" early on so that all output of any programs invoked goes to the
coprocess instead of stdout. Child processes inherit a pipe to the
coprocess, but this isn't a problem that needs to be addressed; it has no
ill effects and certainly doesn't warrant an obnoxious warning I can only
turn off by relying on an undocumented feature.

I certainly agree that the warnings are a good debugging aid, but making
them unnecessarily hard to turn off is, in my opinion, contrary to the unix
philosophy, which entails letting the user shoot himself in the foot if he
wants, and not assuming that your program is necessarily smarter than the
person running it, or that the developer was able to anticipate all
circumstances his or her program might be run in. I think --quiet should get
rid of these warnings too; you should assume that anyone who goes out of
their way to specify --quiet really does want the utility to be quiet except
when critical errors occur. It's what --quiet should do, and what the
documentation implies --quiet does.

Anyway, thank you for the hint about LVM_SUPPRESS_FD_WARNINGS, and sorry
about the ranting.

Andras

-- 
 Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
        When in darkness or in doubt, run in circles, scream and shout.

Message #25 received at 466138@bugs.debian.org (full text, mbox, reply):

From: Alasdair G Kergon <agk@redhat.com>

To: Andras Korn <korn-debbugs@elan.rulez.org>

Cc: 466138@bugs.debian.org

Subject: Re: Bug#466138: Is this LVM message actually useful?

Date: Wed, 8 Jul 2009 18:21:27 +0100

On Wed, Jul 08, 2009 at 04:37:09PM +0200, Andras Korn wrote:
> I don't agree; surely, following the above argumentation, each and every
> program should go out of its way to close any inherited file descriptor it
> didn't expect, and warn the user about them. 

Not every program, but ones that are used by root and potential targets for
exploits should certainly consider it.

> chpst -l (which relies on obtaining a lock on a file and then passing this

That's perhaps one of the few valid reasons for retaining a file descriptor
open, if used safely, but we've never been asked to support it.  (LVM's
internal locking is presumably enough.)

> ill effects and certainly doesn't warrant an obnoxious warning I can only
> turn off by relying on an undocumented feature.

What stops you closing the fd just before the execve()?
lvm will not write to pre-existing fds other than 0, 1 & 2 and lvm is currently
imposing it as a requirement that other fds, which lvm will not use, should be
closed before invocation.
 
> I think --quiet should get
> rid of these warnings too; 

Unfortunately the program structure makes that impossible: these checks
are performed during initialisation, before even looking at any command line.

Alasdair

Message #30 received at 466138@bugs.debian.org (full text, mbox, reply):

From: Andras Korn <korn-debbugs@elan.rulez.org>

To: Alasdair G Kergon <agk@redhat.com>

Cc: 466138@bugs.debian.org

Subject: Re: Bug#466138: Is this LVM message actually useful?

Date: Thu, 9 Jul 2009 00:19:21 +0200

On Wed, Jul 08, 2009 at 06:21:27PM +0100, Alasdair G Kergon wrote:

> > ill effects and certainly doesn't warrant an obnoxious warning I can only
> > turn off by relying on an undocumented feature.
> 
> What stops you closing the fd just before the execve()?

Nothing, I suppose, other than that it adds a difficult to read line with no
obvious purpose to the script (nothing a comment couldn't explain, to be
sure). But I agree it's a workaround (whether it's nicer than the magic
envvar, I couldn't say).

> lvm will not write to pre-existing fds other than 0, 1 & 2 and lvm is currently
> imposing it as a requirement that other fds, which lvm will not use, should be
> closed before invocation.

I'm still not sure I understand why this is such a big deal that it's
unacceptable to just close them silently, but I don't want to argue this
point ad nauseam.

> > I think --quiet should get rid of these warnings too;
> 
> Unfortunately the program structure makes that impossible: these checks
> are performed during initialisation, before even looking at any command line.

Well, the fact that it's difficult to fix doesn't mean it's not broken. :)

Currently, --quiet doesn't work properly because LVM still prints messages
that aren't critical errors.

I wouldn't object to this bug being downgraded to wishlist and retitled to
something like "Please fix --quiet so that it suppresseses the warning about
FDs left open" (it's not my bug, so I won't mess with it myself). Add a
wontfix tag if you think it's never going to be fixed.

However, I think at the very least the magic envvar should be documented for
use in those cases where a stay FD is known to be present and LVM should be
silent. This would help avoid kludges like lvsomething 2>&1 | fgrep -v ...

(And hey, maybe there are even valid uses for stray FDs, only we can't think
of any right now - so that not even closing them may always be desirable.)

Andras

-- 
 Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
             Bathroom scale: Something you stand on and swear at.

Message #35 received at 466138@bugs.debian.org (full text, mbox, reply):

From: Alasdair G Kergon <agk@redhat.com>

To: Andras Korn <korn-debbugs@elan.rulez.org>

Cc: 466138@bugs.debian.org

Subject: Re: Bug#466138: Is this LVM message actually useful?

Date: Thu, 9 Jul 2009 00:08:50 +0100

On Thu, Jul 09, 2009 at 12:19:21AM +0200, Andras Korn wrote:
> I'm still not sure I understand why this is such a big deal that it's
> unacceptable to just close them silently, 

Because the cause needs investigating in case it's a security hole (or other
program bug).  I believe every program has a responsibility to behave defensively
and report upon things it notices like that that are not normal.  When you're
satisfied there's not a security problem, and you don't want to change things
you can choose to add the suppression.  The original bug, by the way, was a
system-wide file descriptor leak (not on Debian), where most processes on the
system (irrespective of uid) gained unintended access to a root-only
File.

> Currently, --quiet doesn't work properly because LVM still prints messages
> that aren't critical errors.

Currently the role of --quiet is simply to disable any pre-configured
verbose or debug settings.  In other words it doesn't do very much useful.

But perhaps we could redefine it to suppress all the pointless "successfully"
messages inherited from LVM1.  In coding terms, to split the 'log_print' macro
into two macros, essential output (like the data from 'lvs') and non-essential
output, and have --quiet suppress the non-essential output.

> I wouldn't object to this bug being downgraded to wishlist and retitled to
> something like "Please fix --quiet so that it suppresseses the warning about
> FDs left open" (it's not my bug, so I won't mess with it myself). Add a
> wontfix tag if you think it's never going to be fixed.

As I indicated, that won't get changed without significant code restructuring,
which is unlikely to happen.
 
> However, I think at the very least the magic envvar should be documented for
> use in those cases where a stay FD is known to be present and LVM should be
> silent. This would help avoid kludges like lvsomething 2>&1 | fgrep -v ...

This bug provides documentation now for anyone searching...
 
Alasdair

Message #40 received at 466138@bugs.debian.org (full text, mbox, reply):

From: Ross Boylan <RossBoylan@stanfordalumni.org>

To: Debian Bug Tracking System <466138@bugs.debian.org>

Subject: lvm2 file descriptors open

Date: Sat, 16 Jan 2010 11:51:15 -0800

Package: lvm2
Version: 2.02.39-7
Followup-For: Bug #466138

I think this is the same kind of issue as in the previous report, though I'm not sure.

>From Jan 5th on a nightly cron job that creates snapshots produces
messages like this for every lvcreate:
<quote>
+ lvcreate -L10G -s -n _home /dev/daisy/home
File descriptor 3 left open
File descriptor 41 left open
File descriptor 42 left open
File descriptor 43 left open
  Logical volume "_home" created
</quote>
The same file descriptors are listed for each group.  I do not see
such messages when I do other commands such as lvs.

The only installs in the previous day were of a locally built,
backported (from sid--I'm on lenny) samba.  These did require
upgrading libpam0g, libpamruntime, libpam-modules to sid,
and installing libdb4.7 from sid. I also upgraded man-db and doc-base
within lenny.

I think the previous discussion implies 
a) my lvcreate's are still working OK and
b) I may have a security problem with some other program.  The new
installs would be the obvious suspects, particularly pam.

I'm looking for confirmation of a) and advice on how to handle b).
Thanks.

P.S. It might also be relevant that I get a parse error from lvm every
time the system starts, at something like byte 3200.  I seem to have
all my volumes, and I don't know where the data is that is being read.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (990, 'stable'), (50, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lvm2 depends on:
ii  libc6                        2.7-18      GNU C Library: Shared libraries
ii  libdevmapper1.02.1           2:1.02.27-4 The Linux Kernel Device Mapper use
ii  libreadline5                 5.2-3.1     GNU readline and history libraries
ii  lsb-base                     3.2-20      Linux Standard Base 3.2 init scrip

Versions of packages lvm2 recommends:
ii  dmsetup                      2:1.02.27-4 The Linux Kernel Device Mapper use

lvm2 suggests no packages.

-- no debconf information

Send a report that this bug log contains spam.