Bug#466138: Is this LVM message actually useful?
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466138: Is this LVM message actually useful?
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466138: Is this LVM message actually useful?
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466138: Is this LVM message actually useful?
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466138: Is this LVM message actually useful?
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 21 | 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466138: Is this LVM message actually useful?
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 21 | fgrep -v ... This bug provides documentation now for anyone searching... Alasdair -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
