Bug#466138: Is this LVM message actually useful?

[Alasdair G Kergon]

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