Ubuntu
dbus package

at_console does not adapt to console changes

Bug #37181 reported by Martin Pitt
28
Affects Status Importance Assigned to Milestone
D-Bus
Won't Fix
Medium
dbus (Ubuntu)
Won't Fix
Wishlist
Unassigned
hal (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Our dbus is meant to treat 'at_console' as 'is at the current foreground console'. However, it evaluates dbus-foreground-console only in bus_policy_create_client_policy(), i. e. at the startup of applications like gnome-{volume,power}-manager. This is wrong, since if you switch user and log in as a second user, both instances will end up as being regarded at the foreground console by dbus. Thus the original intention of preventing races is not implemented at all.

I checked the code, getting that right requires a fair amount of nontrivial code changes. :(

Revision history for this message
Martin Pitt (pitti) wrote :

Robert, any idea how other distributions cope with that problem? Does anyone have time to rework dbus that way?

Revision history for this message
Matt Zimmerman (mdz) wrote :

Martin, I'm questioning the severity and milestone settings here...is this a regression from Breezy?

Revision history for this message
Matthew Garrett (mjg59) wrote :

It's not a regression, but if this isn't fixed we have severe problems with the multiple-user case.

Revision history for this message
Matt Zimmerman (mdz) wrote :

But no worse than the ones in Warty, Hoary or Breezy (or those in many other distributions, presumably?)

Would be great to fix this, but according to Martin it requires significant development, it's quite late in the release cycle, and so it doesn't seem sensible to target this for dapper.

Changed in dbus:
status: Unconfirmed → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

It basically means that we can't rely on at_console at all, which means that we need to change gnome-power-manager (and gnome-volume-manager) to detect the foreground console directly instead of going through dbus. That would mean that the 'only foreground console' policy cannot be enforced by dbus any more, but g-p-m and friends need to take care of that on their own; worse, every remote and system user will be able to suspend or shutdown the computer!

Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 37181] Re: at_console does not adapt to console changes

Hi Matt,

Matt Zimmerman [2006-04-14 18:18 -0000]:
> Martin, I'm questioning the severity and milestone settings
> here...is this a regression from Breezy?

Yes, since in Breezy we didn't use gnome-power-manager.

Revision history for this message
Matt Zimmerman (mdz) wrote :

What are the race conditions mentioned in the original report? How bad are the bugs we face by leaving this as-is?

As authentication goes, if the user logged in at the console, even if their session isn't in the foreground, they're reasonably trusted for these purposes.

Revision history for this message
Matthew Garrett (mjg59) wrote :

User A logs in. His preferences have the machine configured to suspend
after being idle for 15 minutes. He locks his screen and leaves. User B
arrives. She logs in with the "switch user" button, and starts working.
15 minutes after user A became idle, his power manager daemon suspends
the machine.

There are similar issues related to who gets access to hotplugged media.
If user switching is going to be enabled, then this really needs fixing.

--
Matthew Garrett | <email address hidden>

Revision history for this message
Matt Zimmerman (mdz) wrote : Re: [Bug 37181] Re: [Bug 37181] Re: at_console does not adapt to console changes

On Mon, Apr 24, 2006 at 03:34:34PM -0000, Matthew Garrett wrote:
> User A logs in. His preferences have the machine configured to suspend
> after being idle for 15 minutes. He locks his screen and leaves. User B
> arrives. She logs in with the "switch user" button, and starts working.
> 15 minutes after user A became idle, his power manager daemon suspends
> the machine.

Understood, but this seems like rather a corner case, requiring a
combination of non-default power management preferences and multiple console
users.

It's certainly worth fixing, but I think only a straightforward fix would be
appropriate for Dapper. We certainly have bugs with broader impact which
should be fixed instead.

> There are similar issues related to who gets access to hotplugged media.
> If user switching is going to be enabled, then this really needs fixing.

Surely the hotplugged media issues are not new; iirc we have had such
problems since Warty with multiple sessions.

--
 - mdz

Revision history for this message
Martin Pitt (pitti) wrote :

For the record, g-p-m and g-v-m has been changed to use check-foreground-console now, so they work around this bug and do not interfere with peer instances any more. This doesn't prevent a process of a nonactive user from messing with power management, though. But I'm afraid this hack has to do for Dapper.

Revision history for this message
Zunbeltz Izaola (zunbeltz) wrote :

Has been done any work at this bug for edgy? Would it be fixed for the edgy release?

Revision history for this message
In , Martin Pitt (pitti) wrote :

Currently, at_console="true" matches users on a physically local console, and
programs like gnome-volume-manager, gnome-power-manager etc. make heavy use of it.

While this is a good concept for things like avahi, where resources do not
compete on each other, it is not sufficient for nm-applet or
gnome-volume-manager, where concurrent access from multiple users do compete.

Therefore, in Ubuntu we added patches to gnome-volume-manager,
gnome-power-manager, etc. to not issue dbus calls if their console is not the
currently active one (on the foreground). Thus, if two people are logged into
the box (user switching), this avoids the race condition 'who will get ownership
of the plugged in USB stick' or 'inactive user's gpm issues a suspend, and the
active user gets totally surprised by that'.

However, checking for this in the particular apps is not only tedious, but also
wrong from a security perspective; the dbus calls will still work.

To solve this cleanly, I propose a new policy type at_console="foreground", or
foreground_console="yes", or similar.

Revision history for this message
In , Martin Pitt (pitti) wrote :

Created an attachment (id=8089)
broken attempt to implement this

In Ubuntu we experimented with a patch that uses libpam-foreground to
implement this policy (unfortunately we didn't rename the option, but
kept it as at_console, since by that time we did not have an use case
for upstream's semantics; now with avahi we do). Unfortunately it does
not work because dbus resolves the policy statically, so
changes of the foreground console are not respected. But maybe
it has some bits you can recycle.

Revision history for this message
Martin Pitt (pitti) wrote :

Closing unrelated hal task.

Changed in hal:
status: Unconfirmed → Rejected
Revision history for this message
Martin Pitt (pitti) wrote :

I discussed this again with Sebastian. Our new strategy is:

(1) Change the meaning of at_console="true" back to upstream semantics: this applies if the user is on a local console, regardless of whether it is the foreground console.
(2) File a bug upstream asking for a new mode 'at_console="foreground"', 'foreground_console="true"' or similar. As stated earlier, this requires profound code changes.
(3) Until (2) happens, keep our gnome-{volume,power}-manager patches which use check-foreground-console and add the same workaround to nm-applet.

Changed in dbus:
assignee: nobody → pitti
status: Confirmed → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :

This implements step (1) of the previous plan, gets rid of the invasive broken patch, and restores compatibility with upstream semantics:

 dbus (1.0.2-1ubuntu2) feisty; urgency=low
 .
   * debian/patches/80-dbus-change-at-console-policy.patch:
     - Throw away the previous complicated and broken (see LP#37181) patch.
     - Go back to upstream semantics of 'at_console="true"' matching if the
       process is on any local console regardless of whether it is the
       foreground one.
   * debian/dbus.install, debian/dbus.postinst, debian/rules: Revert
     dbus-foreground-console-related changes, since we do not need to install
     any additional programs any more.
   * Remove debian/patches/99_autoreconf.patch: We do not need it any more.
   * For the record, and to ease the next merge, remaining Ubuntu changes:
     - debian/control: Build depend on libselinux1-dev to get SELinux support.
     - debian/patches/81-session.conf-timeout.patch: Raise the service startup
       timeout from 25 to 60 seconds. It may be too short on the live CD with
       slow machines.

Toning down the bug now, waiting for upstream to implement (2).

Changed in dbus:
assignee: pitti → nobody
importance: High → Wishlist
status: In Progress → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in dbus:
status: Unknown → Confirmed
Revision history for this message
In , Johnp-redhat (johnp-redhat) wrote :

Upstream GNOME is working with PolicyKit to correctly resolve multi user policy. I suspect we will deprecate at_console for this method of access control.

Bug Watch Updater (bug-watch-updater)
Changed in dbus:
status: Confirmed → Won't Fix
Revision history for this message
Martin Pitt (pitti) wrote :

We use PolicyKit now, which restricts such actions to the current foreground console. Thus this is not an issue any more.

Changed in dbus:
status: Confirmed → Won't Fix
Bug Watch Updater (bug-watch-updater)
Changed in dbus:
importance: Unknown → Medium
Bug Watch Updater (bug-watch-updater)
Changed in dbus:
importance: Medium → Unknown
Bug Watch Updater (bug-watch-updater)
Changed in dbus:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.