[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: systemd-fsck?

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

> 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

Reply to: