Am Samstag, 10. Mai 2014, 15:38:24 schrieb Steve Langasek: > 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.
I beg to differ. Correct is a definition of people believing in a certain behaviour to be correct. I am more interested in sane, not in supposedly correct behaviour. Let me elaborate: Sure, I agree fixing the dirmngr init script, tested the fix and posted the patch from Maurizio without the word wrap issues onto the bug report. Yet I do not think this fixes all of the reported problem. Why? I am still asked for a password confirmation on hibernating on a single seat system as default behaviour if systemd is running. Why does this do not make much sense to me? Why do I think it *breaks* existing setups in a horrible way? 1) How often did you see more than one user using a single seat machine together without being able to talk about when to hibernate it? How would asking a password help to improve the situation if one of them chooses not to talk about it? 2) How much sense does it make that it just suspends without asking a password then? 3) How much sense does it make that with Network Manager I can just stop the network connection as a user without being asked a password, which in addition to pausing the processes is the only consequence of a longer hibernation? 4) And how about that with current behaviour of KDE it even introduces a security issue on top of annoying the user: KDE first locks the screen, then the password confirmation dialog appears, but invisible behind locker screen. Then the user wonders what is happening here, why the machine does not just hibernate, then the user eventuall unlocks the screen again, sees the password prompt, thinks "WTF!", enters the password and the machine almost immediately hibernates without locking the screen again. Can it get anymore unpredictable and inconsistent for the user? I reported all of this in the bug reports. Yet Laurent merged them all together and reassigned them to dirmngr, which is comfortable for pushing systemd as default as soon as possible. I am not even sure he read the bug reports. Would you like to see the described behaviour as a default on a single seat machine for a user who may happens to open a private and a work session on a laptop? I don´t. > 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. As written elsewhere, by "not breaking it" I also mean to care about "when I still break something for a good reason" to get it fixed there – before having systemd activated on an apt-get dist-upgrade. And considering the points I made above I do not even remotely see a sensible design pattern in here. > 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. I do think that asking for a password on hibernation on a single seat machine is unintuitive, annoying and I would consider it to be a regression over previous behavior. For the reasons I outlined above. > > 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. Yet, systemd does not care about the su sessions I have in a Konsole window on another activity on this KDE setup. And this *makes* a lot of sense. So how is the su session in that init script different? Why does it create a different seat while mine does not? And again: I am fine with the fix for the dirmngr script. > > 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. Yet, before systemd is being pushed as a default, I think its the responsibilty of those doing this to check for existing bugs and take care of having them fixed. If need be by nudging the maintainer or providing an NMU. Yes, I can contribute to this, and with bug reports and providing information I already did… but I did not decide to push systemd as a default… yet I think if I would push it as a default I would accept *some* responsibilty for what I do. That is the whole point I am trying to make. That is what I miss. And I think you wrote something similar here: > 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. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
signature.asc
Description: This is a digitally signed message part.
