Bug#427559: [Pkg-cups-devel] Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: Martin-Éric Racine wrote: On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: Package: cupsys Version: 1.2.11-2 I'm reporting on behalf of a customer who called me today because important functions on his test printserver [running on Sid] broke after upgrading to CUPS 1.2.11-2; He can not use that system any more for now, until he pays money to some- one to fix everything (if that is at all possible; otherwise to migrate it to a non-Debian distro). that I have serious issues with your report on one specific aspect: Your customer is running Testing on a production server that he needs to depend upon for everyday work. No, you didn't read (or exactly memorize) what I wrote. I said it was his *test* print server. Please check. You said test server and yet you report on how this latest upgrade alarmingly broke everything he is running on that. That makes it pretty clear that he depends upon that server for everyday life. * it is totally legal and valid to report bugs and submit wishlist items against a Sid/unstable system irrespective of the fact whether these were acquired on a production system That you guys broke our system and it's gonna cost us a fortune to get it fixed moaning won't help their case, at any rate. It also proves that they actually rely upon that server for everyday use. * some people run Testing and Unstable *now* on their test and pilot systems because they have a long term plan to migrate hundreds of servers and 10s of thousands of workstations to Linux, away from a proprietary system (and by the time of the migration they hope to use a Stable or Testing version) In which case it's just a test server, not a system running a number of scripts and filters they noticably depend upon. I didn't see you participate in any of the detailed discussions that took place on the upstream mailing lists about that particular topic; not once on many occasions over the last 2-3 years when they happened; therefore I do not deem you competent in uttering a verdict about upstream having a patently broken security model. I have been following the issue for longer than that, but whatever. It has become clear to me that you only came here to bicker and to push these maintainers into reverting every change that disagrees with how you would maintain this package. However, I have an even better proposal for you: become the CUPS maintainer in Debian, yourself, right now. Start by triaging the bugs currently open against the package. Then submit patches that show what changes you would like to see in CUPS for Debian (and keep in mind our stated goal to keep differences between the Debian and Ubuntu packages minimal). If you do a good job at it, we'll gladly let Your Expertness take over the package's maintenance and, yes we mean it. :) -- Martin-Éric Racine http://q-funk.iki.fi
Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
tag 427559 confirmed retitle 427559 cupsys: make backend permissions behaviour compatible to upstream thanks Hi Kurt, Kurt Pfeifle [2007-06-04 23:19 +0200]: * you have changed cupsd to run as user cupsys, while upstream CUPS developers have dropped this again (and they gave very good reasons for that) when they released 1.2.0. I had lots of conversations about this with upstream, and none of the reasons he gave justified running cups as root, but that's a different story. * in previous upstream versions when cupsd ran as an unprivileged user, it was possible to use RunAsUser No in cupsd.conf -- you have re- applied that old patch without keeping the user option to not follow your default. Right, because upstream does not want to reintroduce it, so I don't want to make incompatible configuration file options. * you have removed the possibility to run individual backends as root (by simply giving them 0700 permissions and root ownership). You can still do that, and it's done by default with lpd. The backends needs to be set to root:lp 4754. Most of your problems seem to come from incompatible behavior of backend permissions. I agree that we need to do something about it. Documenting it would be one possibility, but I think it is even better to change our cups to become compatible with upstream again wrt. backend permissions. This could be done by a single suid root 'backend runner' instead of having lots of suid root backends. Thanks, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
Martin Pitt wrote: tag 427559 confirmed retitle 427559 cupsys: make backend permissions behaviour compatible to upstream thanks Hi Kurt, Kurt Pfeifle [2007-06-04 23:19 +0200]: * you have changed cupsd to run as user cupsys, while upstream CUPS developers have dropped this again (and they gave very good reasons for that) when they released 1.2.0. I had lots of conversations about this with upstream, and none of the reasons he gave justified running cups as root, but that's a different story. Do you have a link to these conversations (if they were held in public, not in private)? * in previous upstream versions when cupsd ran as an unprivileged user, it was possible to use RunAsUser No in cupsd.conf -- you have re- applied that old patch without keeping the user option to not follow your default. Right, because upstream does not want to reintroduce it, so I don't want to make incompatible configuration file options. You can't expect me to understand that logic without further explanations: So it looks like it is OK for you... ...to make incompatible source code patches, incompatible binary builds, incompatible startup scripts resulting in an incompatible runtime behaviour of cupsd and backends -- but you frown on... ...adding a single new (old) configuration file option that would at least re-enable runtime behaviour compatibility with upstream? * you have removed the possibility to run individual backends as root (by simply giving them 0700 permissions and root ownership). You can still do that, and it's done by default with lpd. The backends needs to be set to root:lp 4754. Thanks. I did not know this [and this change is (a) not documented, (b) not compatible with upstream's behaviour, (c) not compatible with upstream's documentation] I'll try it. However, I suspect that this will not work with some of the customer's backends since some of them are written as Shell scripts. You can't run shell scripts setuid root. Most of your problems seem to come from incompatible behavior of backend permissions. I agree that we need to do something about it. Documenting it would be one possibility, but I think it is even better to change our cups to become compatible with upstream again wrt. backend permissions. This could be done by a single suid root 'backend runner' instead of having lots of suid root backends. Do you already have a timescale for this? If so, please keep in in the loop. Feel free to mail me in private as soon as you have something that I can help testing and evaluating. BTW, upstream was never completely opposed to channges that would let the scheduler run as non-root. They just deemed the solution they used back then as not appropriate, and not adding any effective gain in security (while keeping the software fully functional). They also said that they did not yet come up with a good/better solution themselves, and that they are open to evaluate patches and code anyone feels he could contribute. So maybe your idea of a backend runner is one such contribution. About the real value of such an addition (possible gain in security) I'd rather like to see real security experts evaluate that. I'm not qualified for a verdict here. I'm only qualified for a verdict about having lost functionality, having lost compatibility, and having lost successful printouts. Thanks, Martin Cheers, Kurt -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Fon/Fax: +49-711-4017-5677/-2303 ... Mobile: +49-172-715.7017 Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany --- Infotec Deutschland GmbH Hedelfingerstrasse 58 D-70327 Stuttgart Telefon +49 711 4017-0, Fax +49 711 4017-5752 www.infotec.com Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398 Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren sowie die unbefugte Übermittlung komplett oder in Teilen sind nicht gestattet.Private Ansichten und Meinungen sind, wenn nicht ausdrücklich erklärt, die des Autors und nicht die der Infotec Deutschland GmbH oder deren verantwortliche Direktoren und Angestellte. Eine Haftung für Schäden oder Verlust von Daten durch den Gebrauch dieser Email oder deren Anhänge wird ausgeschlossen. Weitere Informationen erhalten Sie im Internet unter www.infotec.com oder in jeder Infotec Niederlassung. This E-Mail is for the exclusive use of the recipient and may contain information which is confidential. Any disclosure, distribution or copying of
Bug#427559: [Pkg-cups-devel] Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
Martin-Éric Racine wrote: On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: Martin-Éric Racine wrote: On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: Package: cupsys Version: 1.2.11-2 I'm reporting on behalf of a customer who called me today because important functions on his test printserver [running on Sid] broke after upgrading to CUPS 1.2.11-2; He can not use that system any more for now, until he pays money to someone to fix everything (if that is at all possible; otherwise to migrate it to a non-Debian distro). that I have serious issues with your report on one specific aspect: Your customer is running Testing on a production server that he needs to depend upon for everyday work. No, you didn't read (or exactly memorize) what I wrote. I said it was his *test* print server. Please check. You said test server I'm glad that everyone who cares can read for himself if I wrote test printserver or else. and yet you report on how this latest upgrade alarmingly broke everything he is running on that. That makes it pretty clear that he depends upon that server for everyday life. Whatever. What I indeed did want to make pretty clear are these current facts: * your current way of upgrading to CUPS 1.2.11-2 from a previous CUPS 1.2.x version breaks currently working installations * if you do not change $whatever (code, documentation, buildtime configure, startup script, postinstall-script, $wildcard) by the time this upgrade happens in next stable, your users may be hit quite unprepared by some printing b0rkenness Please stop discussing your theories about how this customer may be relying on a Debian Unstable for a production print server. This theory's validity is completely irrelevant to the above two points. * it is totally legal and valid to report bugs and submit wishlist items against a Sid/unstable system irrespective of the fact whether these were acquired on a production system That you guys broke our system and it's gonna cost us a fortune to get it fixed moaning won't help their case, at any rate. OK, please forget this part of my mail. It was also irrelevant to my important points. It also proves that they actually rely upon that server for everyday use. * some people run Testing and Unstable *now* on their test and pilot systems because they have a long term plan to migrate hundreds of servers and 10s of thousands of workstations to Linux, away from a proprietary system (and by the time of the migration they hope to use a Stable or Testing version) In which case it's just a test server, not a system running a number of scripts and filters they noticably depend upon. They do not yet depend on these scripts and filters; but they will, once they migrate to Linux. And their decision to migrate will heavily depend on how well the current tests and pilots work. And current tests and pilots are being run in order to find out any problems now, and to help iron out what can be ironed out... Is that comprehensible? I didn't see you participate in any of the detailed discussions that took place on the upstream mailing lists about that particular topic; not once on many occasions over the last 2-3 years when they happened; therefore I do not deem you competent in uttering a verdict about upstream having a patently broken security model. I have been following the issue for longer than that, but whatever. It has become clear to me that you only came here to bicker and to push these maintainers into reverting every change that disagrees with how you would maintain this package. However, I have an even better proposal for you: become the CUPS maintainer in Debian, yourself, right now. I'm clearly not qualified to be a package maintainer, because I just know too little about building, packaging and Debian policies. My qualification lies elsewhere. One field is what you call bickering, yes. Start by triaging the bugs currently open against the package. In case you did not notice: I *did* already start. Last night. Even before I sent my first reply to you in this thread. And I suggested to close the bug in question (Bug #259774). Then submit patches that show what changes you would like to see in CUPS for Debian (and keep in mind our stated goal to keep differences between the Debian and Ubuntu packages minimal). I'd like to see as little changes compared to upstream pristine sources as possible. Especially, if they are undocumented for the end user. Especially if they change some fundamental behaviour of the software. Especially if they do not explain how to get back the original behaviour. Especially if they disallow to get back the original behaviour. If you do a good job at it, we'll gladly let Your Expertness take over the package's maintenance and, yes we mean it. :) I even trust you on this. Be assured, My Expertness is much more lowly educated than it may appear.
Bug#427559: [Pkg-cups-devel] Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: What I indeed did want to make pretty clear are these current facts: * your current way of upgrading to CUPS 1.2.11-2 from a previous CUPS 1.2.x version breaks currently working installations Correct and, at this early stage of Lenny development, something to be expected. * if you do not change $whatever (code, documentation, buildtime configure, startup script, postinstall-script, $wildcard) by the time this upgrade happens in next stable, your users may be hit quite unprepared by some printing b0rkenness They will not, since the development cycle for Lenny leaves us with enough time to iron things out. In which case it's just a test server, not a system running a number of scripts and filters they noticably depend upon. They do not yet depend on these scripts and filters; but they will, once they migrate to Linux. And their decision to migrate will heavily depend on how well the current tests and pilots work. Evaluating the relevance of migrating to Free Software based on the constantly moving target that is Testing/Unstable is rather crazy, but whatever... Their choice. Start by triaging the bugs currently open against the package. In case you did not notice: I *did* already start. Last night. Even before I sent my first reply to you in this thread. And I suggested to close the bug in question (Bug #259774). Good thing. Thank you for that. Would you care to run through the list of open bugs against CUPS and regroup those pertaining to my printer doesn't work anymore with a usertag of your choice? I'd like to see as little changes compared to upstream pristine sources as possible. Especially, if they are undocumented for the end user. Documentation usually happens later in a Debian release's development cycle. To expect this to be fully documented already at a stage where we barely got these changes into Testing is just plain silly. Especially if they change some fundamental behaviour of the software. Especially if they do not explain how to get back the original behaviour. Especially if they disallow to get back the original behaviour. Those choices tend to be explained in README.Debian, when they occur. However, now is not a good time to ask for this documented, as we are still testing the proper way to package newer CUPS releases. -- Martin-Éric Racine http://q-funk.iki.fi
Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
Package: cupsys Version: 1.2.11-2 (I'm sorry to not be able to use reportbug; I'm reporting on behalf of a customer who called me today because important functions on his test printserver [running on Sid] broke after upgrading to CUPS 1.2.11-2; I'm not running Sid, but I was able to ssh into his system for a few minutes and poke around a bit...) -- It looks like the 1.2.11-2 package changed a few very substantial things over the previous package (1.2.7-4?): * you have changed cupsd to run as user cupsys, while upstream CUPS developers have dropped this again (and they gave very good reasons for that) when they released 1.2.0. * in previous upstream versions when cupsd ran as an unprivileged user, it was possible to use RunAsUser No in cupsd.conf -- you have re- applied that old patch without keeping the user option to not follow your default. * you have removed the possibility to run individual backends as root (by simply giving them 0700 permissions and root ownership). This breaks all customized backends which need root permissions in order to do their job. In our case it was... (a) a custom pdf-creating backend (*NOT* the cups-pdf package) that was geared to work with SAP output, and write its results into specific directories owned by different system users (b) another custom pdf-creating backend (*NOT* the cups-pdf package) which was geared to work for MS Windows domain users via Samba and write its output to user-owned directories (c) a backend using Pykota (http://www.pykota.com/software/pykota) as a printjob accounting software (d) a backend using Tea4CUPs (http://www.pykota.com/software/tea4cups) to fan out (multiply) certain jobs to multiple production printers (e) a backend that reads a hidden file in each user's home directory containing a PIN and a USERCODE to insert these into the PostScript file to enable user specific locked printing on certain printers (f) and 3 more custom backends which I can't talk about here. This change caught the customer completely off guard; it looks like the upgrade did not warn him about such heavy-handed changes when the post- install script ran. He can not use that system any more for now, until he pays money to some- one to fix everything (if that is at all possible; otherwise to migrate it to a non-Debian distro). Moreover, while you introduced these changes (amounting to a de-facto fork from upstream IMHO), you did not sufficiently document these. In fact, the CUPS documentation you ship is still suggesting to the user that his cupsd runs as root. The way you introduced these changes in effect completely takes away users' freedom to run cupsd unchanged in its behavior from upstream's version; and I'm very doubtful if you even added any substantial gain in security with these modifications. If you think you need to protect users from security breeches your way (by adding a non-standard, now old feature back to your current CUPS (a feature that was dropped by the CUPS developers themselves), then please at least do it in a way that still allows to configure away your default (by also re-enabling the RunAsUser No directive in cupsd.conf). Hence, my feature requests: -- either return to the same setup as upstream CUPS sources, -- or do re-enable the RunAsUser No option in cupsd.conf -- and please do at least make it un-mistakenly clear in the CUPS docu at localhost:631/help what you changed and how the user can return to upstream's CUPS behavior for its scheduler and backends. -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany --- Infotec Deutschland GmbH Hedelfingerstrasse 58 D-70327 Stuttgart Telefon +49 711 4017-0, Fax +49 711 4017-5752 www.infotec.com Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398 Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren sowie die unbefugte Übermittlung komplett oder in Teilen sind nicht gestattet.Private Ansichten und Meinungen sind, wenn nicht ausdrücklich erklärt, die des Autors und nicht die der Infotec Deutschland GmbH oder deren verantwortliche Direktoren und Angestellte. Eine Haftung für Schäden oder Verlust von Daten durch den Gebrauch dieser Email oder deren Anhänge wird ausgeschlossen. Weitere Informationen erhalten Sie im Internet unter www.infotec.com oder in jeder Infotec Niederlassung. This E-Mail is for the exclusive use of the recipient and may
Bug#427559: [Pkg-cups-devel] Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: Package: cupsys Version: 1.2.11-2 I'm reporting on behalf of a customer who called me today because important functions on his test printserver [running on Sid] broke after upgrading to CUPS 1.2.11-2; He can not use that system any more for now, until he pays money to some- one to fix everything (if that is at all possible; otherwise to migrate it to a non-Debian distro). I was gonna answer point by point to your very detailed wishlist, except that I have serious issues with your report on one specific aspect: Your customer is running Testing on a production server that he needs to depend upon for everyday work. As far as cretinism goes, this one wins the jackpot. There are two possible solutions to the above bug report's main issues: 1) Your customer must acquire the brains to realize that the only sensible release to run on production servers is Stable and he should therefore immediately downgrade to Etch. 2) As he nonetheless chose to run Testing, he is invited to fix his software to match our changes and help us streamline the transition to non-root user operation, by reporting on actual bugs, rather than on features which we deliberately chose to close uptream's patently broken security model. Moreover, while you introduced these changes (amounting to a de-facto fork from upstream IMHO), you did not sufficiently document these. In fact, the CUPS documentation you ship is still suggesting to the user that his cupsd runs as root. The Debian changelog makes it abundantly clear that we're aware that this is gonna break some things and that Lenny's development cycle exists to iron things out. -- Martin-Éric Racine http://q-funk.iki.fi
Bug#427559: [Pkg-cups-devel] Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
Martin-Éric Racine wrote: On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: Package: cupsys Version: 1.2.11-2 I'm reporting on behalf of a customer who called me today because important functions on his test printserver [running on Sid] broke after upgrading to CUPS 1.2.11-2; He can not use that system any more for now, until he pays money to some- one to fix everything (if that is at all possible; otherwise to migrate it to a non-Debian distro). I was gonna answer point by point to your very detailed wishlist, except Oh, I'm so sorry to have rubbed your skin the wrong way and to have made you giving up on that noble intention! that I have serious issues with your report on one specific aspect: Your customer is running Testing on a production server that he needs to depend upon for everyday work. No, you didn't read (or exactly memorize) what I wrote. I said it was his *test* print server. Please check. As far as cretinism goes, this one wins the jackpot. As far as shooting quickly, but not precisely and rudeness goes, this one surely does not take the last place. There are two possible solutions to the above bug report's main issues: 1) Your customer must acquire the brains Please stop calling anyone any names in a public, archived Debian forum. to realize that the only sensible release to run on production servers is Stable and he should therefore immediately downgrade to Etch. Please realize a few things: * it is his decision what he runs on his test printserver system(s) * it is his decision even if he'd run Sid on his production printserver system * it is totally legal and valid to report bugs and submit wishlist items against a Sid/unstable system irrespective of the fact whether these were acquired on a production system * you should be grateful to receive bug reports for Sid packages at all, wether they originate from user test or from user production systems * whatever Your Majesty may deem sensible for everyone, please do try to understand that *sometimes* Stable packages just do not have the features that someone needs in production, and that some people may have a strong need to run Unstable test systems so that their production systems running Testing or Stable can be early forwarned about upcoming problems * some people run Testing and Unstable *now* on their test and pilot systems because they have a long term plan to migrate hundreds of servers and 10s of thousands of workstations to Linux, away from a proprietary system (and by the time of the migration they hope to use a Stable or Testing version) * you can debate with me in private mail when and when not it is appro- priate to run Stable and/or Unstable; but this public thread started with a bug report/feature request that describes a real problem; that problem will make itself felt in Stable as soon as package makes the transition; therefor it is completely irrelevant if the current feed- back was won from a production or from a testing system. Is that comprehensible? 2) As he nonetheless chose to run Testing, he is invited to fix his software to match our changes and help us streamline the transition to non-root user operation, It is very revealing that you do not see this bug report as an occasion to streamline your changes, Your Honor. by reporting on actual bugs, rather than on features which we deliberately chose to close uptream's patently broken security model. I didn't see you participate in any of the detailed discussions that took place on the upstream mailing lists about that particular topic; not once on many occasions over the last 2-3 years when they happened; therefore I do not deem you competent in uttering a verdict about upstream having a patently broken security model. Moreover, while you introduced these changes (amounting to a de-facto fork from upstream IMHO), you did not sufficiently document these. In fact, the CUPS documentation you ship is still suggesting to the user that his cupsd runs as root. The Debian changelog makes it abundantly clear that we're aware that this is gonna break some things and that Lenny's development cycle exists to iron things out. Whatever. Please document it also in the *user* documentation, that every user looks at first: http://localhost:631/help/. This part of CUPS can be patched as well, ya know? Please do not tolerate that this documentation contradicts what behavior your source code patches along with your compile time changes do change for the user. Can you now say something to my requested changes, puh-leeze? Even if it is WONTFIX?! -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany --- Infotec Deutschland GmbH Hedelfingerstrasse 58 D-70327 Stuttgart Telefon +49 711
