Bug#671726: apt: should be able to provide hook information through a named pipe
On Fri, 16 Aug 2013 23:32:14 +0200 Francesco Poli wrote: On Fri, 16 Aug 2013 11:15:41 +0200 David Kalnischkies wrote: So (just for the record), after discussing this a bit at DebConf it seems like we could apply the attached patch to APT, which is hopefully fine for everyone. Hi David, thanks a lot for the updated patch. I am compiling the modified apt right now, in order to test it with an appropriately modified apt-listbugs... Hi again David, I tested the apt patch along with a modified apt-listbugs. The communication between apt and apt-listbugs through a file descriptor seems to indeed work as intended. I would love to see your patch applied to apt. Thanks a lot for your help! Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp23TTqwUrlb.pgp Description: PGP signature
Bug#671726: apt: should be able to provide hook information through a named pipe
On Sun, Aug 11, 2013 at 10:20 PM, Serafeim Zanikolas s...@debian.org wrote: On Sun, Mar 17, 2013 at 11:52:49PM +0100, Serafeim Zanikolas wrote: On Sun, Mar 17, 2013 at 08:15:32PM +0800, Daniel Hartwig wrote: On 17 March 2013 19:56, Serafeim Zanikolas s...@debian.org wrote: On Sun, Mar 17, 2013 at 02:14:50PM +0800, Daniel Hartwig wrote: The data can be passed through an open fd, similar to dpkg --status-fd argument. Then there are no issues due to filesystems global namespace and it removes the fs as an unrequired middle-man. [..] Attached the updated patches for apt and apt-listbugs, which implement Daniel's proposal of using an fd rather than a fifo. Ping? Is there anything blocking the application of this patch? So (just for the record), after discussing this a bit at DebConf it seems like we could apply the attached patch to APT, which is hopefully fine for everyone. Best regards David Kalnischkies 0001-allow-Pre-Install-Pkgs-hooks-to-get-info-over-an-FD-.patch Description: Binary data
Bug#671726: apt: should be able to provide hook information through a named pipe
On Fri, 16 Aug 2013 11:15:41 +0200 David Kalnischkies wrote: So (just for the record), after discussing this a bit at DebConf it seems like we could apply the attached patch to APT, which is hopefully fine for everyone. Hi David, thanks a lot for the updated patch. I am compiling the modified apt right now, in order to test it with an appropriately modified apt-listbugs... [...] From 48498443e74b2a7e089709b954c50b7df374684b Mon Sep 17 00:00:00 2001 From: David Kalnischkies kalnischk...@gmail.com Date: Tue, 13 Aug 2013 18:18:15 +0200 Subject: [PATCH] allow Pre-Install-Pkgs hooks to get info over an FD != stdin [...] Closes: #671728 Please note that this is not the bug you want to close! You want to close the bug report filed against apt, don't you? That's #671726! Bye and thanks again. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpDmy4tUBn0O.pgp Description: PGP signature
Bug#671726: apt: should be able to provide hook information through a named pipe
Daniel, David, On Sun, Mar 17, 2013 at 11:52:49PM +0100, Serafeim Zanikolas wrote: On Sun, Mar 17, 2013 at 08:15:32PM +0800, Daniel Hartwig wrote: On 17 March 2013 19:56, Serafeim Zanikolas s...@debian.org wrote: On Sun, Mar 17, 2013 at 02:14:50PM +0800, Daniel Hartwig wrote: The data can be passed through an open fd, similar to dpkg --status-fd argument. Then there are no issues due to filesystems global namespace and it removes the fs as an unrequired middle-man. [..] Attached the updated patches for apt and apt-listbugs, which implement Daniel's proposal of using an fd rather than a fifo. Ping? Is there anything blocking the application of this patch? cheers, sez (currently at DebConf) -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: apt-listbugs: please use debconf [was: Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe]
On Tue, 19 Mar 2013 21:03:28 +0100 Serafeim Zanikolas wrote: [...] I think technical minded users would appreciate the same level of options currently provided by apt-get ran as root, ie. to be able to upgrade selected RC-buggy packages while pinning others. To me, it is of paramount importance to refrain from removing features or flexibility from apt-listbugs. In other words, I agree with you: let's not disappoint power users, in order to become friendlier to newbies! Less savvy users (eg. someone who can't tell the different between a DFSG-violation and system-wide breakage) would be served best by upgrading all upgrade-able packages except for those that are RC-buggy. In practise, this means pinning any RC-buggy packages (what the patch for #441689 does) and proceeding with the upgrade (after an apt-get re-invocation, or whatever action is required for the pinning to become effective). Yes, this looks like a possible use case. Do you agree about these use cases or do you have others to suggest as more important? Nothing else comes to my mind for the time being. Anyway, if we manage to add features, without removing previously implemented ones, we should automatically preserve existing use cases (even those we are not aware of!). Back to mechanics: The current non-interactive default (with --force-no) of aborting the whole upgrade in the face of any RC bug means that users are denied of (potentially security-critical) updates to packages that are safely upgrade-able. I consider this unacceptable if we're serious about supporting Debian testing. It's definitely sub-optimal: personally, I would not use apt-listbugs that way, but, after all, I don't consider myself to be a total newbie... This brings us back to the above distinction between more and less sophisticated use cases. Severity based filtering (-s) seems meaningless to me. I'd never do blind upgrades based on a ignore bugs up to X severity policy, because that doesn't say anything about the packages and package features that I rely on as a user. Please note that the current apt-listbugs default behavior is to ignore any non-RC bug. I consider this to be a reasonable default, especially taking into account that the behavior may be configured differently by the user. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp2tBmxK7DwS.pgp Description: PGP signature
Bug#628996: apt-listbugs: please use debconf [was: Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe]
On 19 March 2013 07:07, Francesco Poli invernom...@paranoici.org wrote: On Sun, 17 Mar 2013 17:34:03 +0800 Daniel Hartwig wrote: What follows is a somewhat verbose justification and answer to some of your previous questions. Responses should go to #628996 only, please. Excluding your address and also Serafeim's one? No, I meant only to exclude the other bug report which is now quite unrelated to this topic. :-) Apt-listbugs is run in a similar context as package maintainer scripts. Debian policy #6.3 applies: Maintainer scripts are no longer guaranteed to run with a controlling terminal and must be able to fall back to noninteractive behavior (debconf handles this). Maintainer scripts may abort if there is no controlling terminal and no reasonable default for a high-priority question, but should avoid this if possible. This is already complied with, even though in a somewhat brutal way. Quoting apt-listbugs(1) man page: · -n, --force-no Assumes that you select no for all questions. This option is assumed if stdout is not a terminal or if /dev/tty cannot be opened. Hence, I would say that, when there is no controlling terminal, apt-listbugs falls back to a non-interactive behavior (assuming a negative answer for each question that would otherwise be asked to the user). This implies that, if the upgrade or installation risks introducing RC bugs into the system, then the (non-interactive) apt session is forced to stop. Otherwise, everything goes on, as if apt-listbugs were never invoked. I see. So, except for the previous hanging issue with packagekit, apt-listbugs is more-or-less compliant in its operation and, as per your later comments, its fallback behaviour is somewhat configurable. - abort always when RC bugs. The second is, IMO, the more reasonable default. I believe it's the currently implemented default. Yes. (B) will a DebconfFrontend be (necessary and) enough to make apt-listbugs work well with packagekit? It depends what you mean by ‘work well’. I mean that, during this bug log, I began suspecting that packagekit did not send the hook info to hook scripts. If this is the case, then using debconf would not be enough to let apt-listbugs work with packagekit. This was never clarified. Packagekit-backend-aptcc uses libapt-pkg4.12, which certainly does send the hook information. The reason for the apt-listbugs hanging must lie in some other aspect of the running environment. [...] Though packagekit by design does not allow interaction with the user, Wait, what do you mean? I was under the impression that user interaction through debconf was allowed... Yes, my mistake. Anyway, I think we all like to at least test a debconf interface and get some interaction in situations without /dev/tty. So some project for the near future. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: apt-listbugs: please use debconf [was: Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe]
Hi guys, On Tue, Mar 19, 2013 at 12:07:20AM +0100, Francesco Poli wrote: On Sun, 17 Mar 2013 17:34:03 +0800 Daniel Hartwig wrote: [...] On 17 March 2013 16:17, Francesco Poli invernom...@paranoici.org wrote: [..] · -n, --force-no Assumes that you select no for all questions. This option is assumed if stdout is not a terminal or if /dev/tty cannot be opened. Hence, I would say that, when there is no controlling terminal, apt-listbugs falls back to a non-interactive behavior (assuming a negative answer for each question that would otherwise be asked to the user). This implies that, if the upgrade or installation risks introducing RC bugs into the system, then the (non-interactive) apt session is forced to stop. Otherwise, everything goes on, as if apt-listbugs were never invoked. [..] - abort always when RC bugs. The second is, IMO, the more reasonable default. I believe it's the currently implemented default. Ideally, the minimum severity of bugs to cause abort should be configurable but that is yet another wishlist :-) Assuming I am not misinterpreting what you wrote, this is already possible: by modifying /etc/apt/apt.conf.d/10apt-listbugs the user may add options to the apt-listbugs invocation, among which the -s option may be used to define which bug severities he/she is interested in. It might be useful to forget about mechanics for a moment and think about the use cases that we'd like to support for Debian testing users of high level package managers (packagekit and the like). I think technical minded users would appreciate the same level of options currently provided by apt-get ran as root, ie. to be able to upgrade selected RC-buggy packages while pinning others. Less savvy users (eg. someone who can't tell the different between a DFSG-violation and system-wide breakage) would be served best by upgrading all upgrade-able packages except for those that are RC-buggy. In practise, this means pinning any RC-buggy packages (what the patch for #441689 does) and proceeding with the upgrade (after an apt-get re-invocation, or whatever action is required for the pinning to become effective). Do you agree about these use cases or do you have others to suggest as more important? Back to mechanics: The current non-interactive default (with --force-no) of aborting the whole upgrade in the face of any RC bug means that users are denied of (potentially security-critical) updates to packages that are safely upgrade-able. I consider this unacceptable if we're serious about supporting Debian testing. Severity based filtering (-s) seems meaningless to me. I'd never do blind upgrades based on a ignore bugs up to X severity policy, because that doesn't say anything about the packages and package features that I rely on as a user. -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe
Hi Daniel, On Sun, Mar 17, 2013 at 05:34:03PM +0800, Daniel Hartwig wrote: Control: reopen 628996 Control: retitle 628996 apt-listbugs: please use debconf #Control: tags 628996 - moreinfo On 17 March 2013 16:17, Francesco Poli invernom...@paranoici.org wrote: On Sun, 17 Mar 2013 10:41:52 +0800 Daniel Hartwig wrote: [...] Debconf may provide a suitable interface there Please see the bug log of #628996 for more details about a possible Debconf frontend and the related difficulties... [..] Debconf is the standard way to handle this type of user interaction during Apt activity, and provides more control to the user (i.e. using DEBIAN_FRONTEND and preconfiguring). At the moment, current non-interactive behaviour is one of: - avoid running apt-listbugs, due to work-around for #662983; - abort always when RC bugs. The second is, IMO, the more reasonable default. Ideally, the minimum severity of bugs to cause abort should be configurable but that is yet another wishlist :-) [..] No doubt the current behaviour of noop is not doing apt-listbugs justice. I agree that debconf is generally the best way to handle a situation where terminal interaction may or may not be possible. But as far as I understand, debconf could only be used to set/retrieve a generic policy decision: whether and at what level of severity should packages be pin'ed, right? If that is so, then debconf can not support the current granularity of user interaction: ie. I want to pin this and that package and I'm OK upgrading this other one. If I understand correctly, debconf can only be used with predefined templates, thus predefined generic policy questions (as opposed to questions that can be different on every invocation). If that is so, then debconf would be an improvement over the current noop, but would still leave something be desired. -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe
On 18 March 2013 18:56, Serafeim Zanikolas s...@debian.org wrote: No doubt the current behaviour of noop is not doing apt-listbugs justice. I agree that debconf is generally the best way to handle a situation where terminal interaction may or may not be possible. But as far as I understand, debconf could only be used to set/retrieve a generic policy decision: whether and at what level of severity should packages be pin'ed, right? If that is so, then debconf can not support the current granularity of user interaction: ie. I want to pin this and that package and I'm OK upgrading this other one. If I understand correctly, debconf can only be used with predefined templates, thus predefined generic policy questions (as opposed to questions that can be different on every invocation). Yes, the templates are predefined, but the questions are not. A question is a template with potentially some substitutions made. The substitutions can be arbitrary, including multi-line strings, and there should be little if any flexability lost. Effectively it is no different to printf type string templates, coupled with pre-determined responses (such as, what action to take for pkg X with bugs Y). If that is so, then debconf would be an improvement over the current noop, but would still leave something be desired. The context for scripts in Pre-Install-Pkgs implies several restrictions that the current apt-listbugs interface takes liberties with. To seriously address this involves numerous compromises and limitations being imposed on the interface, at least when called via the Apt hook. Anyway, the direction is clear so lets see when work begins. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: apt-listbugs: please use debconf [was: Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe]
On Sun, 17 Mar 2013 17:34:03 +0800 Daniel Hartwig wrote: [...] On 17 March 2013 16:17, Francesco Poli invernom...@paranoici.org wrote: On Sun, 17 Mar 2013 10:41:52 +0800 Daniel Hartwig wrote: [...] Debconf may provide a suitable interface there Please see the bug log of #628996 for more details about a possible Debconf frontend and the related difficulties... Thanks. I reopen that bug I knew that mentioning that old bug report would cause it to be revamped... :-/ Do you think you should set yourself as submitter of the bug report? as the current workaround (i.e. making apt-listbugs a no-op) is not adequate. I agree that disabling apt-listbugs for packagekit users is sub-optimal, as I myself commented a while ago on this very bug log. What follows is a somewhat verbose justification and answer to some of your previous questions. Responses should go to #628996 only, please. Excluding your address and also Serafeim's one? Apt-listbugs is run in a similar context as package maintainer scripts. Debian policy #6.3 applies: Maintainer scripts are no longer guaranteed to run with a controlling terminal and must be able to fall back to noninteractive behavior (debconf handles this). Maintainer scripts may abort if there is no controlling terminal and no reasonable default for a high-priority question, but should avoid this if possible. This is already complied with, even though in a somewhat brutal way. Quoting apt-listbugs(1) man page: · -n, --force-no Assumes that you select no for all questions. This option is assumed if stdout is not a terminal or if /dev/tty cannot be opened. Hence, I would say that, when there is no controlling terminal, apt-listbugs falls back to a non-interactive behavior (assuming a negative answer for each question that would otherwise be asked to the user). This implies that, if the upgrade or installation risks introducing RC bugs into the system, then the (non-interactive) apt session is forced to stop. Otherwise, everything goes on, as if apt-listbugs were never invoked. Debconf is the standard way to handle this type of user interaction during Apt activity, I agree that using debconf would improve the flexibility of user interaction. As I have previously said in this very bug log, I had difficulties in figuring out how a program written in Ruby can interact with the user through debconf. and provides more control to the user (i.e. using DEBIAN_FRONTEND and preconfiguring). At the moment, current non-interactive behaviour is one of: - avoid running apt-listbugs, due to work-around for #662983; Wait, the workaround for bug #662983 was implemented exactly to switch to non-interactive behavior in the absence of a controlling terminal... - abort always when RC bugs. The second is, IMO, the more reasonable default. I believe it's the currently implemented default. Ideally, the minimum severity of bugs to cause abort should be configurable but that is yet another wishlist :-) Assuming I am not misinterpreting what you wrote, this is already possible: by modifying /etc/apt/apt.conf.d/10apt-listbugs the user may add options to the apt-listbugs invocation, among which the -s option may be used to define which bug severities he/she is interested in. [...] Francesco, you previously asked two questions: Open questions: (A) how can a program written in Ruby use debconf to interact with the user? Any program can directly use the debconf protocol as documented in debconf-devel(7). No library is required, though some minor changes to initiate debconf interaction will be. If I recall correctly, I tried to understand how to do this, but failed miserably... :-( There is a sh library, and probably perl and python also. These may or may not be useful. (B) will a DebconfFrontend be (necessary and) enough to make apt-listbugs work well with packagekit? It depends what you mean by ‘work well’. I mean that, during this bug log, I began suspecting that packagekit did not send the hook info to hook scripts. If this is the case, then using debconf would not be enough to let apt-listbugs work with packagekit. This was never clarified. [...] Though packagekit by design does not allow interaction with the user, Wait, what do you mean? I was under the impression that user interaction through debconf was allowed... other Apt frontends have trouble with apt-listbugs (e.g. aptitude) Wait, let's not dramatize. I use aptitude with apt-listbugs everyday. The only trouble is that users should become root with su - before invoking aptitude, rather than starting it from their regular account and relying on the internal gain-root-privileges mechanism. [...] I am not a user of apt-listbugs, I would like to encourage you to give it a try and familiarize with it, so that you may find out more about its strengths and weaknesses. though I do value its place in the Apt world
Bug#671726: apt: should be able to provide hook information through a named pipe
On 17 March 2013 06:56, Serafeim Zanikolas s...@debian.org wrote: Hi Francesco, On Sat, Mar 16, 2013 at 11:25:36PM +0100, Francesco Poli wrote [edited]: On Sat, 16 Mar 2013 12:05:09 +0100 David Kalnischkies wrote: [..] Using a hook-defined fifoname rather than a random fifoname should be okay as the later isn't more secure than the former (if an attacker has root rights to write to it we are doomed anyway …) Please excuse my ignorance: isn't a pre-defined fifoname prone to a symlink attack? It's prone only in a publicly-writable directory, which is not the case for /var/run. and in fact creating a randomly named fifo could be hard in practice … Isn't there anything like mkstemp(3) for named pipes? I'm not aware of any -- but we can get away without one anyway. The data can be passed through an open fd, similar to dpkg --status-fd argument. Then there are no issues due to filesystems global namespace and it removes the fs as an unrequired middle-man. I guess the apt-listbugs patch is just for testing, but I say it non-the-less: It would be good if at least apt-listbugs/wheezy would support both so we don't create backport problems that early in the (not even started) wheezy release cycle. ;) At this point of the wheezy freeze, I cannot introduce any change into apt-listbugs/wheezy, except for those that fix important or RC bugs. Due to this issue and current work-around for #662983, the functionality of the package is severly downgraded. Introducing a new interface (named pipe or open fd) is desirable for the reasons David says, and has potential for wheezy especially if backed by the apt developers. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe
On Sun, 17 Mar 2013 10:41:52 +0800 Daniel Hartwig wrote: [...] Debconf may provide a suitable interface there Please see the bug log of #628996 for more details about a possible Debconf frontend and the related difficulties... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpX9WeUTb8xH.pgp Description: PGP signature
Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe
Control: reopen 628996 Control: retitle 628996 apt-listbugs: please use debconf #Control: tags 628996 - moreinfo On 17 March 2013 16:17, Francesco Poli invernom...@paranoici.org wrote: On Sun, 17 Mar 2013 10:41:52 +0800 Daniel Hartwig wrote: [...] Debconf may provide a suitable interface there Please see the bug log of #628996 for more details about a possible Debconf frontend and the related difficulties... Thanks. I reopen that bug as the current workaround (i.e. making apt-listbugs a no-op) is not adequate. What follows is a somewhat verbose justification and answer to some of your previous questions. Responses should go to #628996 only, please. Apt-listbugs is run in a similar context as package maintainer scripts. Debian policy #6.3 applies: Maintainer scripts are no longer guaranteed to run with a controlling terminal and must be able to fall back to noninteractive behavior (debconf handles this). Maintainer scripts may abort if there is no controlling terminal and no reasonable default for a high-priority question, but should avoid this if possible. Debconf is the standard way to handle this type of user interaction during Apt activity, and provides more control to the user (i.e. using DEBIAN_FRONTEND and preconfiguring). At the moment, current non-interactive behaviour is one of: - avoid running apt-listbugs, due to work-around for #662983; - abort always when RC bugs. The second is, IMO, the more reasonable default. Ideally, the minimum severity of bugs to cause abort should be configurable but that is yet another wishlist :-) Using debconf in combination with updates to the APT hook protocol (#671726) will restore functionality, avoid the current /dev/tty hacks, work with the maximum number of Apt frontends (packagekit, aptitude, apt-get, wajig, etc.) and provide more flexability. In particular, interaction with the user is possibly available with any debconf frontend, even in the absense of a controlling terminal. Apt-listbugs provides a safe guard against introducing known RC bugs to a system. I believe we all agree that it should not be disabled simply due to lack of /dev/tty access, and that it should also take the maximum opportunity to interact with the user. Francesco, you previously asked two questions: Open questions: (A) how can a program written in Ruby use debconf to interact with the user? Any program can directly use the debconf protocol as documented in debconf-devel(7). No library is required, though some minor changes to initiate debconf interaction will be. There is a sh library, and probably perl and python also. These may or may not be useful. (B) will a DebconfFrontend be (necessary and) enough to make apt-listbugs work well with packagekit? It depends what you mean by ‘work well’. ‘Work well’ can not require the presence of an interactive terminal, as given debian policy #6.3 quoted above [1]. It will be enough to at least have a sensible and configurable non-interactive default, and provide greater opportunity to interact with the user through non-terminal debconf frontends. Though packagekit by design does not allow interaction with the user, other Apt frontends have trouble with apt-listbugs (e.g. aptitude) and using debconf will certainly facilitate more interaction here. I am not a user of apt-listbugs, though I do value its place in the Apt world and do not wish it to become a second class citizen rought with work-arounds and pitfalls. I will contribute some effort to the development of a debconf interface after the Wheezy release. Regards [1] If you disagree with this, then apt-listbugs is not suitable for hooking in to Apt's Pre-Install-Pkgs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe
On Sun, Mar 17, 2013 at 12:36:22AM +0100, Francesco Poli wrote: On Sun, 17 Mar 2013 00:07:21 +0100 Serafeim Zanikolas wrote: Do you agree then that adding the fifo feature to apt and adapting apt-listbugs accordingly is not needed nor does it suffice for fixing #662983? No, I don't agree. If I recall bug #662983 correctly, the trick is that, if apt-listbugs can read hook info through a named pipe, then it may interact with the user through stdin and stdout *without* having to explicitly reopen /dev/tty (this is the operation which is forbidden within an su -c command). Francesco, thank you for the clarification. This does make sense now. I think this is due to the fact that your patch for apt-listbugs does not modify what apt-listbugs does *after* parsing the hook info sent by apt. ie. not re-open /dev/tty -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: apt: should be able to provide hook information through a named pipe
On Sun, Mar 17, 2013 at 02:14:50PM +0800, Daniel Hartwig wrote: On 17 March 2013 06:56, Serafeim Zanikolas s...@debian.org wrote: Hi Francesco, On Sat, Mar 16, 2013 at 11:25:36PM +0100, Francesco Poli wrote [edited]: On Sat, 16 Mar 2013 12:05:09 +0100 David Kalnischkies wrote: [..] Using a hook-defined fifoname rather than a random fifoname should be okay as the later isn't more secure than the former (if an attacker has root rights to write to it we are doomed anyway …) Please excuse my ignorance: isn't a pre-defined fifoname prone to a symlink attack? It's prone only in a publicly-writable directory, which is not the case for /var/run. and in fact creating a randomly named fifo could be hard in practice … Isn't there anything like mkstemp(3) for named pipes? I'm not aware of any -- but we can get away without one anyway. The data can be passed through an open fd, similar to dpkg --status-fd argument. Then there are no issues due to filesystems global namespace and it removes the fs as an unrequired middle-man. Sure, that'd be an improvement. Would you make apt pass the fd number to apt-listbugs in the command line? I guess the apt-listbugs patch is just for testing, but I say it non-the-less: It would be good if at least apt-listbugs/wheezy would support both so we don't create backport problems that early in the (not even started) wheezy release cycle. ;) At this point of the wheezy freeze, I cannot introduce any change into apt-listbugs/wheezy, except for those that fix important or RC bugs. Due to this issue and current work-around for #662983, the functionality of the package is severly downgraded. Introducing a new interface (named pipe or open fd) is desirable for the reasons David says, and has potential for wheezy especially if backed by the apt developers. While I appreciate the backing, I seriously doubt that anyone could make a convincing case for a deep freeze exception, for a feature that's not even fully developed yet (and that's not even that relevant for stable). -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: apt: should be able to provide hook information through a named pipe
On 17 March 2013 19:56, Serafeim Zanikolas s...@debian.org wrote: On Sun, Mar 17, 2013 at 02:14:50PM +0800, Daniel Hartwig wrote: The data can be passed through an open fd, similar to dpkg --status-fd argument. Then there are no issues due to filesystems global namespace and it removes the fs as an unrequired middle-man. Sure, that'd be an improvement. Would you make apt pass the fd number to apt-listbugs in the command line? or just using a well known env. variable that will also work with substituation in the command line. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: apt: should be able to provide hook information through a named pipe
On Sun, Mar 17, 2013 at 08:15:32PM +0800, Daniel Hartwig wrote:
On 17 March 2013 19:56, Serafeim Zanikolas s...@debian.org wrote:
On Sun, Mar 17, 2013 at 02:14:50PM +0800, Daniel Hartwig wrote:
The data can be passed through an open fd, similar to dpkg --status-fd
argument. Then there are no issues due to filesystems global
namespace and it removes the fs as an unrequired middle-man.
Sure, that'd be an improvement. Would you make apt pass the fd number to
apt-listbugs in the command line?
or just using a well known env. variable that will also work with
substituation in the command line.
Attached the updated patches for apt and apt-listbugs, which implement
Daniel's proposal of using an fd rather than a fifo.
The HookFifoFilename option is replaced by:
DPkgs::Tools::Options::/usr/sbin/apt-listbugs::HookAvoidStdin yes;
The default value of Pipes[0] (the fd to be inherited and read by
apt-listbugs) was normally 3, which seems to be FD_CLOEXEC'd somewhere before
the exec to apt-listbugs (apt-listbugs was failing with EBADF), so I'm using
instead 20 as a minimum.
--
Every great idea is worthless without someone to do the work. --Neil Williams
diff --git a/apt-listbugs b/apt-listbugs
index 58d67cb..b387947 100755
--- a/apt-listbugs
+++ b/apt-listbugs
@@ -289,7 +289,19 @@ when apt
puts if $DEBUG
puts Pre-Install-Pkgs hook info: if $DEBUG
state=1
- STDIN.each { |pkg|
+ apt_hook_fd = ENV[AptHookFd]
+ if apt_hook_fd.nil?
+ $stderr.puts sprintf(_(E: AptHookFd is undefined))
+ exit(1)
+ end
+ begin
+ apt_hook_stream = IO.open(apt_hook_fd, 'r')
+ rescue Errno::ENOENT
+$stderr.puts sprintf(_(W: Cannot open file descriptor %s), apt_hook_fd)
+exit(1)
+ end
+
+ apt_hook_stream.each { |pkg|
pkg=pkg.rstrip
case state
when 1
@@ -353,6 +365,7 @@ when apt
end
end
}
+ apt_hook_stream.close
puts if $DEBUG
when list, rss
ARGV.each { |pkg|
diff --git a/apt-pkg/deb/dpkgpm.cc b/apt-pkg/deb/dpkgpm.cc
index 6cb8bc6..dabf48c 100644
--- a/apt-pkg/deb/dpkgpm.cc
+++ b/apt-pkg/deb/dpkgpm.cc
@@ -328,8 +328,9 @@ bool pkgDPkgPM::SendV2Pkgs(FILE *F)
// DPkgPM::RunScriptsWithPkgs - Run scripts with package names on stdin /*{{{*/
// -
/* This looks for a list of scripts to run from the configuration file
- each one is run and is fed on standard input a list of all .deb files
- that are due to be installed. */
+ each one is run and is fed on standard input (or another fd, if
+ HookAvoidStdin is set) a list of all .deb files that are due to be
+ installed. */
bool pkgDPkgPM::RunScriptsWithPkgs(const char *Cnf)
{
Configuration::Item const *Opts = _config-Tree(Cnf);
@@ -352,10 +353,14 @@ bool pkgDPkgPM::RunScriptsWithPkgs(const char *Cnf)
unsigned int Version = _config-FindI(OptSec+::Version,1);
+ // Feed subprocess via stdin, unless HookAvoidStdin is true
+ bool const UseStdin = !_config-FindB(OptSec+::HookAvoidStdin,false);
+
// Create the pipes
int Pipes[2];
if (pipe(Pipes) != 0)
return _error-Errno(pipe,Failed to create IPC pipe to subprocess);
+ if (UseStdin == true)
SetCloseExec(Pipes[0],true);
SetCloseExec(Pipes[1],true);
@@ -364,7 +369,21 @@ bool pkgDPkgPM::RunScriptsWithPkgs(const char *Cnf)
if (Process == 0)
{
// Setup the FDs
+ if (UseStdin == true)
dup2(Pipes[0],STDIN_FILENO);
+ else
+ {
+ // small fd numbers (5) are closed down the process tree, so use
+ // a higher number instead
+ int ChildReadFd = fcntl(Pipes[0], F_DUPFD, 20);
+ if (ChildReadFd 0)
+ return _error-Errno(fcntl,Failed to duplicate file descriptor);
+ char AptHookEnv[80];
+ if (sprintf(AptHookEnv, AptHookFd=%d, ChildReadFd) 0)
+ return _error-Errno(sprintf,Failed to contruct environment variable value);
+ if (putenv(AptHookEnv) != 0)
+ return _error-Errno(putenv,Failed to set environment variable AptHookFd);
+ }
SetCloseExec(STDOUT_FILENO,false);
SetCloseExec(STDIN_FILENO,false);
SetCloseExec(STDERR_FILENO,false);
Bug#671726: apt: should be able to provide hook information through a named pipe
Hi David Francesco, Thanks for the quick feedback. On Sat, Mar 16, 2013 at 12:05:09PM +0100, David Kalnischkies wrote [edited]: Using a hook-defined fifoname rather than a random fifoname should be okay as the later isn't more secure than the former (if an attacker has root rights to write to it we are doomed anyway …) and in fact creating a randomly named fifo could be hard in practice … Exactly my thinking. I guess the apt-listbugs patch is just for testing, but I say it non-the-less: It would be good if at least apt-listbugs/wheezy would support both so we don't create backport problems that early in the (not even started) wheezy release cycle. ;) Indeed apt-listbugs is mostly for testing and unstable. The apt-listbugs releases that ship with a fifo option will version-depend on the earliest apt release that supports the feature. In the unlikely event of a backport of apt-listbugs, we could always revert apt-listbugs to use stdin. Francesco, To test the patch you have to temporarily point /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12 to build/bin/libapt-pkg.so in an apt checkout (and of course apply the patch to /usr/sbin/apt-listbugs). This new apt feature opens the way for #671728, but really fixing the latter would also require a non-interactive apt-listbugs frontend (to be used for programmatic invocation). cheers, sez -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: apt: should be able to provide hook information through a named pipe
On 16 March 2013 22:07, Serafeim Zanikolas s...@debian.org wrote: This new apt feature opens the way for #671728, but really fixing the latter would also require a non-interactive apt-listbugs frontend (to be used for programmatic invocation). Right. Apt-listbugs is effectively called in the same context as maintainer scripts, and those are not guaranteed to have an interactive shell. The program must be smart enough to detect this and do the right thing (I'm not sure if it already does :-). This is all regardless of the aptitude–su–login issue that prompted this bug report IIRC. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: apt: should be able to provide hook information through a named pipe
On Sat, Mar 16, 2013 at 10:32:40PM +0800, Daniel Hartwig wrote: Right. Apt-listbugs is effectively called in the same context as maintainer scripts, and those are not guaranteed to have an interactive shell. The program must be smart enough to detect this and do the right thing (I'm not sure if it already does :-). By default, apt-listbugs relies on /dev/tty, but that can be overriden via the APT_LISTBUGS_FRONTEND env variable. The only valid frontend alternative at the moment is none, which makes apt-listbugs a noop (to avoid hanging when invoked non-interactively). The idea would be to add a programmatic or so frontend, which would rely on some form of IPC instead of the terminal. This is all regardless of the aptitude–su–login issue that prompted this bug report IIRC. Indeed. In fact, I'm not sure any more that using a fifo instead of stdin is needed for a programmatic frontend. After all, the tracebacks in #662983 suggest that the failure occurs only when apt-listbugs tries to access /dev/tty, at which point it has already parsed the apt hook data from stdin. Francesco, am I missing something? -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe
On Sat, 16 Mar 2013 16:04:38 +0100 Serafeim Zanikolas wrote: [...] I'm not sure any more that using a fifo instead of stdin is needed for a programmatic frontend. After all, the tracebacks in #662983 suggest that the failure occurs only when apt-listbugs tries to access /dev/tty, at which point it has already parsed the apt hook data from stdin. It seems to me that you are right: if I recall correctly, the failure indeed happens after the hook info parsing step. Anyway, implementing a new alternative frontend is an even more radical modification for apt-listbugs. Let's not forget that here we were only talking about fixing #671726 and #671728 (in order to fix #662983 in a better way)... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpx5G7XfGFzH.pgp Description: PGP signature
Bug#671726: apt: should be able to provide hook information through a named pipe
On Sat, 16 Mar 2013 12:05:09 +0100 David Kalnischkies wrote: On Sat, Mar 16, 2013 at 8:42 AM, Serafeim Zanikolas s...@debian.org wrote: The attached patch enables apt to pass Pre-Install-Pkgs hook data via a fifo, instead of via stdin (which remains the default, of course). Unlike the proposal in the initial bug report, the fifo filename is not randomised, but instead declared via the following configuration option in /etc/apt/apt.conf.d/10apt-listbugs: Thanks! Hello David, hi Serafeim! A big thank you to Serafeim from my side as well, for addressing this issue. Looks good to me (, but I haven't tested it yet). I cannot comment on the apt patch, since I am not familiar with apt internals (unfortunately!). Using a hook-defined fifoname rather than a random fifoname should be okay as the later isn't more secure than the former (if an attacker has root rights to write to it we are doomed anyway …) Please excuse my ignorance: isn't a pre-defined fifoname prone to a symlink attack? Only relying on proper write permissions for the directory where the fifo is created (/var/run/, which should be writable for root only) seems a bit weak to me... Or am I completely off-track? and in fact creating a randomly named fifo could be hard in practice … Isn't there anything like mkstemp(3) for named pipes? So, does this patch provides what you need Francesco? I guess it does (probably), except for the security concerns I expressed. But please note that I haven't had any time at all to look at the patch in detail or to test it. Unfortunately, I am going through really hard days (actually, months) and from now on I will have slower and intermittent Internet connectivity for a while. This means that I am currently unable to dedicate a significant amount of time to this issue. I am enormously sorry about that. :-( I guess the apt-listbugs patch is just for testing, but I say it non-the-less: It would be good if at least apt-listbugs/wheezy would support both so we don't create backport problems that early in the (not even started) wheezy release cycle. ;) At this point of the wheezy freeze, I cannot introduce any change into apt-listbugs/wheezy, except for those that fix important or RC bugs. The release team seems to be so unreasonable that I could not even obtain an unblock for translation updates and documentation fixes, *just* because I was late by a *couple of days* with respect to a freeze policy change that was not even announced in advance!:-( See bug #692928 for details... Hence, I am afraid that any change (for apt-listbugs) to progress on the present issue will *not* migrate into testing until wheezy is released as stable... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp4Q_NCbg9A2.pgp Description: PGP signature
Bug#671726: apt: should be able to provide hook information through a named pipe
Hi Francesco, On Sat, Mar 16, 2013 at 11:25:36PM +0100, Francesco Poli wrote [edited]: On Sat, 16 Mar 2013 12:05:09 +0100 David Kalnischkies wrote: [..] Using a hook-defined fifoname rather than a random fifoname should be okay as the later isn't more secure than the former (if an attacker has root rights to write to it we are doomed anyway …) Please excuse my ignorance: isn't a pre-defined fifoname prone to a symlink attack? It's prone only in a publicly-writable directory, which is not the case for /var/run. and in fact creating a randomly named fifo could be hard in practice … Isn't there anything like mkstemp(3) for named pipes? I'm not aware of any -- but we can get away without one anyway. -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe
On Sat, Mar 16, 2013 at 11:25:18PM +0100, Francesco Poli wrote: On Sat, 16 Mar 2013 16:04:38 +0100 Serafeim Zanikolas wrote: [...] I'm not sure any more that using a fifo instead of stdin is needed for a programmatic frontend. After all, the tracebacks in #662983 suggest that the failure occurs only when apt-listbugs tries to access /dev/tty, at which point it has already parsed the apt hook data from stdin. It seems to me that you are right: if I recall correctly, the failure indeed happens after the hook info parsing step. Do you agree then that adding the fifo feature to apt and adapting apt-listbugs accordingly is not needed nor does it suffice for fixing #662983? Anyway, implementing a new alternative frontend is an even more radical modification for apt-listbugs. Let's not forget that here we were only talking about fixing #671726 and #671728 (in order to fix #662983 in a better way)... #662983, ie. relying on tty input, is not fixed by switching to a fifo: I've reproduced the issue with fifo-based apt apt-listbugs. I see no other way than a non-interactive frontend (but this is a discussion we shouldn't have on an apt bug report). -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe
On Sun, 17 Mar 2013 00:07:21 +0100 Serafeim Zanikolas wrote: On Sat, Mar 16, 2013 at 11:25:18PM +0100, Francesco Poli wrote: On Sat, 16 Mar 2013 16:04:38 +0100 Serafeim Zanikolas wrote: [...] I'm not sure any more that using a fifo instead of stdin is needed for a programmatic frontend. After all, the tracebacks in #662983 suggest that the failure occurs only when apt-listbugs tries to access /dev/tty, at which point it has already parsed the apt hook data from stdin. It seems to me that you are right: if I recall correctly, the failure indeed happens after the hook info parsing step. Do you agree then that adding the fifo feature to apt and adapting apt-listbugs accordingly is not needed nor does it suffice for fixing #662983? No, I don't agree. If I recall bug #662983 correctly, the trick is that, if apt-listbugs can read hook info through a named pipe, then it may interact with the user through stdin and stdout *without* having to explicitly reopen /dev/tty (this is the operation which is forbidden within an su -c command). Please see http://bugs.debian.org/662983#25 http://bugs.debian.org/662983#30 http://bugs.debian.org/662983#40 http://bugs.debian.org/662983#45 Anyway, implementing a new alternative frontend is an even more radical modification for apt-listbugs. Let's not forget that here we were only talking about fixing #671726 and #671728 (in order to fix #662983 in a better way)... #662983, ie. relying on tty input, is not fixed by switching to a fifo: I've reproduced the issue with fifo-based apt apt-listbugs. I think this is due to the fact that your patch for apt-listbugs does not modify what apt-listbugs does *after* parsing the hook info sent by apt. I hope that all this makes sense and that I am not too tired to reply in a reasonable way... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp5dgjcdDNlF.pgp Description: PGP signature
Bug#671726: apt: should be able to provide hook information through a named pipe
On 16 March 2013 23:04, Serafeim Zanikolas s...@debian.org wrote: On Sat, Mar 16, 2013 at 10:32:40PM +0800, Daniel Hartwig wrote: Right. Apt-listbugs is effectively called in the same context as maintainer scripts, and those are not guaranteed to have an interactive shell. The program must be smart enough to detect this and do the right thing (I'm not sure if it already does :-). By default, apt-listbugs relies on /dev/tty, but that can be overriden via the APT_LISTBUGS_FRONTEND env variable. The only valid frontend alternative at the moment is none, which makes apt-listbugs a noop (to avoid hanging when invoked non-interactively). The idea would be to add a programmatic or so frontend, which would rely on some form of IPC instead of the terminal. Actually, I was refering to the standard frontend just not seeking input when it is not connected to an interactive terminal. This would be, for example, displaying the list of bugs and proceeding, or some other configurable action depending on the severity, etc.. This is the same as maintainer scripts behave: with sensible defaults in the non-interactive case. Anyway, I recall I already discussed all this on the original bug report that made its way to aptitude. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: apt: should be able to provide hook information through a named pipe
On 17 March 2013 09:18, Daniel Hartwig mand...@gmail.com wrote: On 16 March 2013 23:04, Serafeim Zanikolas s...@debian.org wrote: On Sat, Mar 16, 2013 at 10:32:40PM +0800, Daniel Hartwig wrote: Right. Apt-listbugs is effectively called in the same context as maintainer scripts, and those are not guaranteed to have an interactive shell. The program must be smart enough to detect this and do the right thing (I'm not sure if it already does :-). By default, apt-listbugs relies on /dev/tty, but that can be overriden via the APT_LISTBUGS_FRONTEND env variable. The only valid frontend alternative at the moment is none, which makes apt-listbugs a noop (to avoid hanging when invoked non-interactively). The idea would be to add a programmatic or so frontend, which would rely on some form of IPC instead of the terminal. Debconf may provide a suitable interface there, as well as supporting: Actually, I was refering to the standard frontend just not seeking input when it is not connected to an interactive terminal. This would be, for example, displaying the list of bugs and proceeding, or some other configurable action depending on the severity, etc.. This is the same as maintainer scripts behave: with sensible defaults in the non-interactive case. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: apt: should be able to provide hook information through a named pipe
tag 671726 +patch
thanks
Hi,
The attached patch enables apt to pass Pre-Install-Pkgs hook data via a fifo,
instead of via stdin (which remains the default, of course).
Unlike the proposal in the initial bug report, the fifo filename is not
randomised, but instead declared via the following configuration option in
/etc/apt/apt.conf.d/10apt-listbugs:
DPkg::Tools::Options::/usr/sbin/apt-listbugs::HookFifoFilename
/var/run/apt-listbugs-hook
I've tested the patch successfully with a locally modified version of
apt-listbugs, so as to make it read from the fifo instead of stdin (see second
patch, if you're interested).
This bug is one of the issues that's blocking integration of apt-listbugs with
higher level package managers (which would be nice for Debian testing users,
who are more likely to use a GUI package manager than directly apt-get).
thanks,
sez
--
Every great idea is worthless without someone to do the work. --Neil Williams
diff --git a/apt-pkg/deb/dpkgpm.cc b/apt-pkg/deb/dpkgpm.cc
index 6cb8bc6..e84a6db 100644
--- a/apt-pkg/deb/dpkgpm.cc
+++ b/apt-pkg/deb/dpkgpm.cc
@@ -328,8 +328,9 @@ bool pkgDPkgPM::SendV2Pkgs(FILE *F)
// DPkgPM::RunScriptsWithPkgs - Run scripts with package names on stdin /*{{{*/
// -
/* This looks for a list of scripts to run from the configuration file
- each one is run and is fed on standard input a list of all .deb files
- that are due to be installed. */
+ each one is run and is fed on standard input (or on a FIFO, if
+ HookFifoFilename is set) a list of all .deb files that are due to be
+ installed. */
bool pkgDPkgPM::RunScriptsWithPkgs(const char *Cnf)
{
Configuration::Item const *Opts = _config-Tree(Cnf);
@@ -351,20 +352,35 @@ bool pkgDPkgPM::RunScriptsWithPkgs(const char *Cnf)
OptSec = DPkg::Tools::Options:: + string(Opts-Value.c_str(),Pos);
unsigned int Version = _config-FindI(OptSec+::Version,1);
-
- // Create the pipes
+
+ // Feed subprocess via stdin, unless HookFifoFilename is set
+ string const FifoFilename = _config-Find(OptSec+::HookFifoFilename);
+ bool const UseFifo = (FifoFilename.empty() != true);
+
int Pipes[2];
- if (pipe(Pipes) != 0)
- return _error-Errno(pipe,Failed to create IPC pipe to subprocess);
- SetCloseExec(Pipes[0],true);
- SetCloseExec(Pipes[1],true);
+
+ // Create pipes or fifo
+ if (UseFifo == true)
+ {
+ // try to remove stale hook fifo if it exists
+ if ((unlink(FifoFilename.c_str()) == -1) (errno != ENOENT))
+return _error-Errno(unlink,Failed to remove stale hook fifo);
+ if (mkfifo(FifoFilename.c_str(), 600) == -1)
+return _error-Errno(mkfifo,Failed to create hook fifo);
+ } else {
+ if (pipe(Pipes) != 0)
+return _error-Errno(pipe,Failed to create IPC pipe to subprocess);
+ SetCloseExec(Pipes[0],true);
+ SetCloseExec(Pipes[1],true);
+ }
// Purified Fork for running the script
pid_t Process = ExecFork();
if (Process == 0)
{
// Setup the FDs
- dup2(Pipes[0],STDIN_FILENO);
+ if (UseFifo == false)
+ dup2(Pipes[0],STDIN_FILENO);
SetCloseExec(STDOUT_FILENO,false);
SetCloseExec(STDIN_FILENO,false);
SetCloseExec(STDERR_FILENO,false);
@@ -378,8 +394,15 @@ bool pkgDPkgPM::RunScriptsWithPkgs(const char *Cnf)
execv(Args[0],(char **)Args);
_exit(100);
}
- close(Pipes[0]);
- FILE *F = fdopen(Pipes[1],w);
+
+FILE *F;
+if (UseFifo == true)
+{
+F = fopen(FifoFilename.c_str(), w);
+} else {
+close(Pipes[0]);
+F = fdopen(Pipes[1],w);
+}
if (F == 0)
return _error-Errno(fdopen,Faild to open new FD);
@@ -409,7 +432,10 @@ bool pkgDPkgPM::RunScriptsWithPkgs(const char *Cnf)
fclose(F);
// Clean up the sub process
- if (ExecWait(Process,Opts-Value.c_str()) == false)
+ int RetStatus = ExecWait(Process,Opts-Value.c_str());
+ if ((UseFifo == true) (unlink(FifoFilename.c_str()) == -1))
+ return _error-Errno(unlink,Failed to remove hook fifo);
+ if (RetStatus == false)
return _error-Error(Failure running script %s,Opts-Value.c_str());
}
diff --git a/apt-listbugs b/apt-listbugs
index 58d67cb..bed944f 100755
--- a/apt-listbugs
+++ b/apt-listbugs
@@ -289,7 +289,15 @@ when apt
puts if $DEBUG
puts Pre-Install-Pkgs hook info: if $DEBUG
state=1
- STDIN.each { |pkg|
+ apt_fifo_filename = /var/run/apt-listbugs-hook
+ begin
+ apt_fifo_fd = open(apt_fifo_filename, 'r')
+ rescue Errno::ENOENT
+$stderr.puts sprintf(_(W: Cannot open %s), apt_fifo_filename)
+exit(1)
+ end
+
+ apt_fifo_fd.each { |pkg|
pkg=pkg.rstrip
case state
when 1
@@ -353,6 +361,7 @@ when apt
end
end
}
+ apt_fifo_fd.close
puts if $DEBUG
when list, rss
Bug#671726: apt: should be able to provide hook information through a named pipe
On Sat, Mar 16, 2013 at 8:42 AM, Serafeim Zanikolas s...@debian.org wrote: The attached patch enables apt to pass Pre-Install-Pkgs hook data via a fifo, instead of via stdin (which remains the default, of course). Unlike the proposal in the initial bug report, the fifo filename is not randomised, but instead declared via the following configuration option in /etc/apt/apt.conf.d/10apt-listbugs: Thanks! Looks good to me (, but I haven't tested it yet). Using a hook-defined fifoname rather than a random fifoname should be okay as the later isn't more secure than the former (if an attacker has root rights to write to it we are doomed anyway …) and in fact creating a randomly named fifo could be hard in practice … So, does this patch provides what you need Francesco? I guess the apt-listbugs patch is just for testing, but I say it non-the-less: It would be good if at least apt-listbugs/wheezy would support both so we don't create backport problems that early in the (not even started) wheezy release cycle. ;) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671726: apt: should be able to provide hook information through a named pipe
Package: apt
Version: 0.8.15.10
Severity: wishlist
Dear APT deity team,
I am one of the co-maintainers of the apt-listbugs package.
Currently, apt-listbugs is automatically invoked by apt-get and aptitude
(and other compatible package managers) thanks to the following
Pre-Install-Pkgs hook:
$ cat /etc/apt/apt.conf.d/10apt-listbugs
// Check all packages whether they has critical bugs before they are
installed.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {/usr/sbin/apt-listbugs apt || exit 10;};
DPkg::Tools::Options::/usr/sbin/apt-listbugs ;
DPkg::Tools::Options::/usr/sbin/apt-listbugs::Version 2;
// AptListbugs::IgnoreRegexp FTBFS;
apt-listbugs reads the input provided by apt(itude) through
the Pre-Install-Pkgs hook info protocol version 2; this input is
provided to apt-listbugs on its stdin, as through a pipe.
This has recently become problematic, due to a security fix in package
login, version 1:4.1.5-1 .
See bug #662983 for more details on this issue.
I have implemented a temporary work around for bug #662983,
but it's rather unsatisfactory, frankly speaking...
In order to implement a more radical fix for this issue,
I would need a new feature in apt(itude): the hook protocol version 2
information should be sent through a dedicated named pipe, rather
than to the stdin of the invoked command.
This named pipe should be created in a safe way (as done by mktemp,
for instance), fed with the hook information which will be read by
the command invoked by the hook, and then (after the command exited),
destroyed properly. It would be ideal, if the name of the FIFO were
made available on the commandline as a variable $HOOKPIPE .
This behavior should be enabled by an appropriate option.
That way, I could modify apt-listbugs so that it could read the hook
information from a file the name of which would be passed as a commandline
argument:
$ cat /etc/apt/apt.conf.d/10apt-listbugs
// Check all packages whether they has critical bugs before they are
installed.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {/usr/sbin/apt-listbugs apt $HOOKPIPE || exit 10;};
DPkg::Tools::Options::/usr/sbin/apt-listbugs ;
DPkg::Tools::Options::/usr/sbin/apt-listbugs::Version 2;
DPkg::Tools::Options::/usr/sbin/apt-listbugs::Hookpipe yes;
// AptListbugs::IgnoreRegexp FTBFS;
I hope this may be implemented soon.
Thanks for your time and for maintaining one of the most crucial packages
in Debian!
-- Package-specific info:
-- (/etc/apt/preferences present, but not submitted) --
-- (/etc/apt/sources.list present, but not submitted) --
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (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 apt depends on:
ii debian-archive-keyring 2010.08.28
ii gnupg 1.4.12-4
ii libc6 2.13-32
ii libgcc1 1:4.7.0-3
ii libstdc++6 4.7.0-3
ii zlib1g 1:1.2.6.dfsg-2
apt recommends no packages.
Versions of packages apt suggests:
ii apt-doc none
ii aptitude0.6.6-1
ii bzip2 1.0.6-1
ii dpkg-dev1.16.2
ii lzma9.22-2
ii python-apt 0.8.3+nmu1
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
