dbus upgrade issue

[Ray Strode]

Hi,


> Hmm, the exit() seems plain wrong; better behavior would be to just
> ignore the new config file. So step 1 is to just be sure we patch this bug.
Sure.  Does the first patch in my original mail look okay?

> However - are you sure this is due to HUP?
Yes, the event is triggered by a raise(SIGHUP) call in bus/selinux.c
when selinux-policy-targeted gets installed during the yum
transaction.

> If it is due to HUP, I believe I complained at one point about a
> "killall -HUP dbus-daemon" in the init script that should have only
> killed the particular pid... whether or not that's the source of the
> problem, in general I'm not sure HUP'ing the *session* buses on upgrade
> is appropriate. I think it would be fine for the session bus config to
> be loaded only at login time and never again, or maybe only on explicit
> HUP by the user.
Sounds right to me.  The raise(SIGHUP) should maybe be changed to code
that explicitly reparses just
/etc/selinux/targeted/contexts/dbus_contexts

> Assuming we aren't moving the config file anyway (let's keep the /etc
> vs. datadir issue separate from this issue), this seems like an
> overreaction to me. Surely there's a less disruptive solution.
Well, a few possibilities were considered:

1) Try to enforce ordering constraints in the yum transaction such
that selinux policy always gets installed first, the SIGHUP gets sent
early, and dbus rereads its old, compatible config file.  This would
work okay if there was an easy way to do that.

One idea was to add a Conflicts: selinux-policy-targeted <
current-version This doesn't actually work.  It just ensures both dbus
and selinux-policy-targeted get into the transaction, but doesn't
specify any ordering.

Another idea was to add a PreReq: selinux-policy-targeted >=
current-version. This is less desirable, because it forces users to
have selinux-policy-targeted installed on their systems.  It's also
not sufficient for people who run strict policy, and it falls over if
the user does two yum update transactions with selinux-policy-targeted
and dbus in them before logging out.

2) Install selinux policy that prevents dbus from sending a hangup
signal to itself.

One problem was that we weren't sure if we could get it installed and
active without triggering the hangup first.

Another problem is that dbus runs in unconfined_t so we can't remove
the ability to raise(SIGHUP) without breaking all other apps that
depend on being able to raise(SIGHUP) and are run in unconfined_t
context.

3) keep the old config file in place for the duration of the
transaction and fix it up after the user logs out.

While this would work, it would break rpm -V dbus. It's also not clear
how we would hook into logout.  We could potentially do it on reboot
(in an init script maybe?), but it would mean the user would be
running an old config file until they reboot (even though they may
have logged in and logged out several times and are already running
the new bus daemon).  Messing with the config files after they're
installed seems a little fragile though.

4) Don't use the new config option in the config file we ship.  This
might be a good enough solution for now (although we'd lose the
<standard_session_servicedirs /> functionality unless we hacked it
without the option), but it's not future proof.  If dbus gains a new
config option later, the same problem could happen again.

5) keep an old compatible config file in place, and move the new
config file to a new location.  This is the option I went for, because
it seemed like the most robust/workable option out of the bunch.

> Have you thought about the upgrade scenarios if you do this? For
> example, if there are new security policies required for HAL to work,
> and you have moved the security policy files to /usr/share, the running
> system daemon will never see the new policies.
Well, like I said, my changes don't move /etc/dbus-1/system.d .
That's a fairly compelling argument to not move it at all without
going to dbus-2.

> Remember also that RPM either can't replace a directory with a symlink
> or vice versa, I don't remember which, in any case it seems a bit scary.
That's quite true.  mharris had to do some really gross hacks to
exchange the various X11 symlinks for actual directories to support
upgrades from monolithic X to modular X a while back.  I think going
the other way is okay, but its still probably better to avoid doing
any kind of symlink<->directory change over if we can help it.

> There may be cases where editing the file is required; for example, I
> don't think we allow removing a listen address in the -local.conf, there
> may be other things that are impossible to override in -local.conf.
> AFAIK the conf file has not been audited or designed in such a way that
> the .d/-local are always enough.
Can we extend the format so that it is enough?  If we put "settings
the distribution should handle" with "settings the sys admin should
handle" in the same file it makes it very difficult for a distribution
to toggle a default.  We're left with either 1) throwing the
sysadmin's changes in a .rpmsave file somewhere and clobbering them in
the place where the daemon looks 2) throwing the new defaults in a
.rpmnew and hoping the sysadmin will merge them for us 3) doing evil
things in %post with sed/perl (which can get tricky if the file is
xml!)

Maybe we could add a <nolisten/> tag that overrides <listen> earlier
in the file? Or do something along the lines of /etc/gdm/custom.conf
versus /usr/share/gdm/defaults.conf where one file sits atop the other
one, overriding just the settings that overlap?

> I believe a number of things in /etc are like this; dbus did not invent
> the -local/.d approach....  you'd have to ask an FHS geek what the
> Official Word is.
Any FHS geeks reading the list?

> Doing this in a Fedora-specific patch I consider a bad idea, fwiw. There
> is nothing Fedora-specific about the /etc vs. /usr/share issue, and
> these file locations are something of an application interface.
If we end up having to diverge in FC-6 to fix the update problem, and
this is an application interface, maybe we should make it queryable
(with pkgconfig?).

I can imagine there are already cases where dbus is installed in other
prefixes, although I realize that's not exactly the same as Fedora
shifting files from sysconfdir to datadir.

> > One thing I'm not moving for FC-6 is the /etc/dbus-1/system.d
> > directory because a lot of packages depend on it being there.  It
> > might make sense to move it, though, and create a compatibility
> > symlink.
>
> I think you'd find this creates a world of pain (and cross-distribution
> incompatibility) if done only in Fedora. Even if done globally, it will
> be a nasty migration period just due to apps trying to run on both old
> and new distributions.
Yea, it does seem like a bad idea.

--Ray