On Sat, May 10, 2014 at 04:00:39PM +0200, Martin Steigerwald wrote: > > The root cause of this bug is in the initscript of dirmngr that us using > > su instead of start-stop-daemon. > > su is starting a PAM session which then call pam_systemd. This > > should not happen for daemons. > > Again here systemd is only doing what he's instructed to do; not > > allowing a user to create a DOS for other logged in users. So please > > get dirmngr fixed instead of blaming systemd/logind. I've reopened the > > initial bug opened against dirmngr about the fact that the initscript > > is calling su (#668890) > Thats exactly the kind of reaction I meant: > Frankly, I just *don´t* care where it is fixed. If its in dirmngr, fine. > Yet: I do think its about high time systemd developers and packagers adopt > an attitude of "never break userspace" like the kernel developers do. I consider it of the highest importance that the transition to systemd not break running systems. But Laurent is correct here: the bug in this case is in dirmngr, not in systemd. It's not reasonable to hold systemd to blame when other packages that were using wrong interfaces now have their bugs exposed because of logind. In fact, I'm surprised that this particular bug in dirmngr wasn't already a problem *before* systemd, since consolekit's behavior (including the integration with PAM sessions) was nearly identical. Laurent is not being a systemd apologist by pointing this out. I know from the PAM bugs I've worked with him on that he cares deeply about getting the core structure of session handling right in Debian. But doing that in a fashion that's maintainable over the long term means having a *design*, and stable *interfaces* that are supported - not a blanket promise to never break anything in the system that is relying on unintended side effects of the current implementation. Some of the regressions introduced are going to turn out to be bugs in systemd. Some of them are going to turn out to be latent bugs in other packages that are exposed by the transition to systemd. The important thing here is that Debian developers (and bug reporters) work constructively *with* the systemd maintainers to properly isolate the cause of the bugs, so that we can move forward together towards a stable jessie with systemd as the default... instead of wasting all our energy throwing blame at each other for the bugs that happen along the way, leaving none left for the actual bug fixing. > The plain fact: > Using systemd breaks something that worked for probably a decade or longer > before however long that su is in that init script. So on what account do > you call calling "su" in an init script a bug? It may not be the most > elegant solution to do things, granted, but a bug? Come on. Calling it a > bug just cause systemd / policykit treat calling su in an initscript as > they do is quite arrogant in my eyes. As the maintainer of the pam package in Debian, I assure you: this is a bug in dirmngr. System services should not (must not) call interfaces that launch pam sessions as part of their init scripts. su is one of those interfaces. > Telling "Go away, the bug is elsewhere" is just not an approbiate reaction > for developers of a low level system component. Approbiate in my eyes > would be caring and helping along with the issue to be fixed no matter > where the fix will land in. I.e. provide help and a patch for dirmngr, If someone wants to provide a patch to dirmngr, kudos to them. But it's the responsibility of the dirmngr maintainer to fix this, not the responsibility of the systemd maintainers, and no package maintainer worth his salt should have any difficulty replacing 'su' with 'start-stop-daemon' in an init script... especially considering 'start-stop-daemon' is the default shown in the /etc/init.d/skeleton example. Now, this *is* an example of why it's bad for systemd to have started pulling itself into people's systems before the sysvinit default has been switched, and shows that we should only make the switch of default in concert and after extensive testing. But the responsibility for fixing the bug still lies with the maintainer of the buggy package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature