Created attachment 241003 [details]
Screenshot

Michael, please check if you can run:
1. /usr/lib/YaST2/bin/y2base users gtk
2. /usr/lib/YaST2/bin/y2base users qt

The GTK one works (without the error window), the qt one says "couldn't load plug-in qt".

Thanks. Now please try to run:
  /sbin/yast2 users

Also, please clarify whether "/usr/lib/YaST2/bin/y2controlcenter-gnome" doesn't function when you run it as an user or as root (make sure you use "su -").

Ha, we are getting close. Both commands work properly if run as a user.

If I run "su -" and then try to run either, none of them starts (unable to connect to display etc)

If I run "su" (no " -") and then run

- /sbin/yast2 users: I see a similar warning as above on the console but no popup

- /usr/lib/YaST2/bin/y2controlcenter-gnome: same thing as above (warnings on console and a warning window)

Thanks. I wanted to make sure this wasn't technically a YaST-GTK issue, but a SLAB one (which is the tool that powers the application-browser and the y2controlcenter-gnome one). Let's try to forward this to those guys.

SLAB bugs seem to usually take a long time to fix though, so you might want to try to remove root's .gconf* stuff or maybe the .gnome2* ones to get a working system in the meanwhile (of course, don't actually remove them, just "mv" them to some "-old" suffix).

By the way, also please fill the Hardware fill (is the machine 32 or 64-bit?). It seems like 64-bit don't seem to get tested as much and I've seen weird issues on those...

*** Bug 429103 has been marked as a duplicate of this bug. ***

This is a general problem, not specific to slab - you get the same problem running "gnomesu -- gedit" or  "gnomesu -- /sbin/yast2 users"

(y2base:11390): GVFS-RemoteVolumeMonitor-WARNING **: cannot connect to the session bus: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Ricardo, this is running on a 32bit installation btw

Scott, so this is a gnomesu bug? I guess we will not see the PolicyKit based replacement ("AdminKit") in time for 11.1? 

*** Bug 431712 has been marked as a duplicate of this bug. ***

This issue also exists in SLED 11 beta2.

*** Bug 416259 has been marked as a duplicate of this bug. ***

*** Bug 432442 has been marked as a duplicate of this bug. ***

The strace shows that this is a dbus connection issue:

16377 1223391260.932703 socket(PF_FILE, SOCK_STREAM, 0) = 10
16377 1223391260.932789 connect(10, {sa_family=AF_FILE, path=@"/tmp/dbus-8BHfXVtkxb"...}, 23) = 0
16377 1223391260.933097 fcntl64(10, F_GETFL) = 0x2 (flags O_RDWR)
16377 1223391260.933152 fcntl64(10, F_SETFL, O_RDWR|O_NONBLOCK) = 0
16377 1223391260.933203 fcntl64(10, F_GETFD) = 0
16377 1223391260.933252 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
16377 1223391260.933312 geteuid32()     = 0
16377 1223391260.933397 rt_sigaction(SIGPIPE, {0x1, [PIPE], SA_RESTART}, {0x1, [PIPE], SA_RESTART}, 8) = 0
16377 1223391260.933541 poll([{fd=10, events=POLLOUT}], 1, 0) = 1 ([{fd=10, revents=POLLOUT}])
16377 1223391260.933611 write(10, "\0"..., 1) = 1
16377 1223391260.933777 write(10, "AUTH EXTERNAL 30\r\n"..., 18) = 18
16377 1223391260.933989 poll([{fd=10, events=POLLIN}], 1, -1) = 1 ([{fd=10, revents=POLLIN}])
16377 1223391260.934063 read(10, "OK bd30a413e4acf4efc2d643a848eb322c\r\n"..., 2048) = 37
16377 1223391260.934163 poll([{fd=10, events=POLLOUT}], 1, -1) = 1 ([{fd=10, revents=POLLOUT}])
16377 1223391260.950622 write(10, "BEGIN\r\n"..., 7) = 7
16377 1223391260.950949 poll([{fd=10, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=10, revents=POLLIN|POLLOUT|POLLHUP}])
16377 1223391260.951041 read(10, ""..., 2048) = 0
16377 1223391260.951098 close(10)       = 0
16377 1223391260.951168 gettimeofday({1223391260, 951184}, NULL) = 0
16377 1223391260.951340 write(2, "GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details -  1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)\n"..., 504) = 504

I wonder what 31337 security policy we are using to stop root talking to the user's session bus :-)

Created attachment 243993 [details]
dbus verbose output

So - by re-building my dbus with --enable-verbose-mode, and exporting DBUS_VERBOSE=1 as per the dbus-daemon man-page etc. I got a nice trace - which I attach - of someone running dbus-monitor from a gnomesu -- xterm.

The highlight would be things like:

2983: client fd 10 accepted
2983: Creating new client connection with fd 10
...
2983: handling read watch 0xb7f2f028 flags = 1
2983: exchange_credentials: do_reading = 1, do_writing = 0
2983: read credentials byte
2983: Credentials:  pid 3082  uid 0
2983:  server auth state: waiting for input
2983: check_read_watch: fd = 10
2983:   setting read watch enabled = 1
2983:   UNLOCK: protected_change_watch
2983:   LOCK: protected_change_watch
2983: check_write_watch(): needed = 0 on connection 0xb7f2f230 watch 0xb7f25080 fd = 10 outgoing messages exist 0
2983:   UNLOCK: protected_change_watch
2983:   LOCK: protected_change_watch
2983: do_reading: fd = 10
...
2983: handling read watch 0xb7f2f028 flags = 1
2983: exchange_credentials: do_reading = 1, do_writing = 0
2983:  server auth state: waiting for input
2983:  read 18 bytes in auth phase
2983: server: got command "AUTH EXTERNAL 30"
2983: server: Trying mechanism EXTERNAL
2983: server: data: '0'
2983: Using cache for UID 0 information
2983: server: going from state WaitingForAuth to state WaitingForBegin
2983: server: authenticated client based on socket credentials
2983: exchange_credentials: do_reading = 1, do_writing = 0
2983:  server auth state: bytes to send
...
2983: handling write watch, have_outgoing_messages = 0
2983: exchange_credentials: do_reading = 0, do_writing = 1
2983:  server auth state: bytes to send
2983: server: Sent 37 bytes of: OK 3a4f10d84613f832386808d448eb822b^M

2983: exchange_credentials: do_reading = 0, do_writing = 1
2983:  server auth state: waiting for input
2983: check_read_watch: fd = 10
...
2983: handling read watch 0xb7f2f028 flags = 1
2983: exchange_credentials: do_reading = 1, do_writing = 0
2983:  server auth state: waiting for input
2983:  read 7 bytes in auth phase
2983: server: got command "BEGIN"
2983: server: going from state WaitingForBegin to state Authenticated
2983: unlock auth_via_unix_user_function
2983:   UNLOCK: _dbus_connection_unlock
2983:   LOCK: dbus_connection_get_data
2983:   UNLOCK: dbus_connection_get_data
2983: Using cache for UID 0 information
2983: UID 0 allowed = 0
2983: lock auth_via_unix_user_function post unix user function
2983:   LOCK: _dbus_connection_lock
2983: Client UID 0 was rejected, disconnecting
2983: _dbus_transport_disconnect start
2983: socket_disconnect

Hopefully that edges us closer to understanding why root's authentication doesn't fly.

I guess the 'no' comes from bus_context_allow_unix_user -> bus_policy_allow_unix_user 

which does some:

allowed = list_allows_user (... policy->default_rules ... ) 

etc.

It really looks like a simple session bus mis-configuration.

*** Bug 433204 has been marked as a duplicate of this bug. ***

Adding <allow user="*" /> inside the session.conf's default policy fixes the problem. As you also need the session cookie to access the bus, this might be acceptable practice.

*** Bug 432445 has been marked as a duplicate of this bug. ***

I think the right fix is not to allow all users' to connect to each other's session busses (I think) - that sounds like rather a recipe for problems; but instead to special case root; adding:

    <!-- Allow anyone to own anything -->
     <allow own="*"/>
+    <allow user="root" />
   </policy>

to my /etc/dbus-1/session.conf fixes the issue for me, and of course just allows root to connect to each user's session bus: which should be no real extension of their privileges anyway.

Can you do that hpj ?

I tried adding 
    <!-- Allow anyone to own anything -->
     <allow own="*"/>
+    <allow user="root" />
   </policy>

to my session.conf but it did not solve my problem. I have to run "xhost +" for any root command to work.

Michael: But then you won't be able to run programs on behalf of test users, or other users if you're a sysadmin. The bus addresses look like this:

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-t6qA1CktFG,guid=92f3cd6297bc5c02c693338648d9336d

Isn't that latter part a secret cookie that would prevent other users from connecting to your session bus? Unless they have access to your env vars, of course.

Erik: That's a different problem, see bug 428118.

Weelll - true, but this other use-case; of running programs as test users seems of somewhat more limited usefulness. I would be more worried about letting random users connect to logged-in root's message bus ;-)

Surely fast-user-switching handles the case of testing things running as other users when logged in as root ? (or if people do this a lot - we can add a commented-out line in session.conf to help them ?) - I'm not sure I've done this log in as root & try to run things as users in recent memory.

I'd prefer to be cautious here, unless you strongly object ;-)

It'll probably generate a couple of bugs that we'll have to WONTFIX, but I don't feel strongly about it, and the commented-out line seems like a good compromise.

Created attachment 244772 [details]
dbus-allow-root-access-to-session-bus.patch

Created submitreq to home:thoenig:Factory with the above patch.

Timo: The ball's in your court.

*** Bug 435107 has been marked as a duplicate of this bug. ***

hpj, thanks for the patch.  It's in now.

Closing as fixed.

*** Bug 435101 has been marked as a duplicate of this bug. ***

This looks to be still present in build0074.

*** Bug 436129 has been marked as a duplicate of this bug. ***

Yes, don't see the recent changelog in autobuild.

I have accepted the osc submit request before closing this bug.

--snip--
State of submit-request #2639 was changed by thoenig:

  new -> accepted

Comment:

  Acknowledged


Source 
  project:  home:hpjansson:branches:home:thoenig:Factory
  package:  dbus-1
  revision: 156f53b5900ceb0f3ab8f9f5c055092a
--snip--

That's what hermes@suse.de sent me.  Stefan, you should know better about the actual check-in?

thoenig@zimtstern:~/devel/home:thoenig:Factory/dbus-1> osc up                  
At revision ad696a0ca000913fccd8fba28fcd2c58.
thoenig@zimtstern:~/devel/home:thoenig:Factory/dbus-1> head -n 5 dbus-1.changes
-------------------------------------------------------------------
Thu Oct  9 20:44:10 CDT 2008 - hpj@novell.com

- Add dbus-allow-root-access-to-session-bus.patch (bnc#428963).

Interesting. According to my information the dbus-package on build0074 was the newest one. Let's see perhaps it was checked in this morning.
You are expecting too much of me, I don't know every check-in personally :) Thanks for the information, Timo. Let's see if obs is slow or some runtime error :) happened.

So is this bug still present even when the patched package is installed, or not?

Argh, I need a new laptop. This touchpad is getting mouseclicks through pressure on the side. Re-opened comment.
Hans Petter: I have no fixed package ready at the moment. 

I'm fine with closing this again and reopening if the new package does not help.

Stefan: You don't have a fixed package?  I submitted it, see above?

Anyway.  Should I submit it via traditional way to STABLE?  What's going wrong here?

No idea what going wrong. I'll investigate this tomorrow. I am pretty convinced that you did everything right, and in a timely manner. 

I tested it, with the patch the error messages are gone. so I just need to find out where that package has gone to.. :)

This is great.  Thanks for getting back.  Makes my sleep a little more comfortable ;-)

At least for B3 of SLES it's not fixed, reopening now (Build 0075)

Right, I've seen that, too. The fix didn't make it into the build system for whatever reason.  I've notified Stefan and he told me that he's already working on a solution.

We agreed to put d-bus for SLES in the update-channel, to avoid another build.
It will be available there after the beta3s are released and check-in has started anew. 

*** Bug 437965 has been marked as a duplicate of this bug. ***

*** Bug 438077 has been marked as a duplicate of this bug. ***

*** Bug 438184 has been marked as a duplicate of this bug. ***

the fix looks

a) wrong
b) dangerous

wrong because why should root access a user's session bus? What does root want to call there? Could it be that this is by accident and some gui su program calls su instead of su - therefore preserving DBUS_SESSION_BUS_ADDRESS?

dangerous because libdbus will autolaunch a session bus if there is none. In that case there are dbus-launch processes hanging around that expose the necessary arguments to reconstruct the session bus address. Therefore any user can gain access to the session bus.

(In reply to comment #52 from Ludwig Nussel)

> the fix looks
> 
> a) wrong
> b) dangerous
> 
> wrong because why should root access a user's session bus? What does root want
> to call there? Could it be that this is by accident and some gui su program
> calls su instead of su - therefore preserving DBUS_SESSION_BUS_ADDRESS?
> 
> dangerous because libdbus will autolaunch a session bus if there is none. In
> that case there are dbus-launch processes hanging around that expose the
> necessary arguments to reconstruct the session bus address. Therefore any user
> can gain access to the session bus.

Right, I didn't think about autolaunched session buses.

As all this worked before I suspect some change in gnomesu -- however, the following works for me:

$ cat print-session.sh && gnomesu ./print-session.sh
#/bin/sh
echo $DBUS_SESSION_BUS_ADDRESS 
unix:abstract=/tmp/dbus-lM4AAX8FVx,guid=9082ee69f365677be77a6f8f49057de7

The problem really is the exported DBUS_SESSION_BUS_ADDRESS variable. When unsetting that variable before running gnomesu the problem goes away. So IMHO the solution would be to clear the environment for the root shell in gnomesu, just like su - does.

I fail to see how this is a blocker.

Re. wrong: User may want to run programs running as root in his session. We've had plenty of bugs on that previously.

Re. dangerous: I don't see how exactly this would happen. If dbus-launch exposes session auth details to everyone, wouldn't that be a bug in D-Bus?

Like jpr, I also don't think this is a blocker. Lowering.

(In reply to comment #56 from Hans Petter Jansson)

> Re. wrong: User may want to run programs running as root in his session. We've
> had plenty of bugs on that previously.

We never had this reports for 11.0 or earlier.  From my point of view I can assure there wasn't a change in D-Bus itself which would cause those *new* defects.  We have to look somewhere else.

The current patch for the session.conf hides the real problem.  That is obviously not what we want.

The real bug is, that the application launched via gnomesu is trying to access the session owner's session bus.

The question is:  Why does it want to access it?

I'm in favor of un-setting DBUS_SESSION_BUS_ADDRESS on changing the user with gnomesu.  By running anything which changes your identity (su $USER, gnomesu $APP, etc.) you're simply out of bounds of the current session.  
 
> Re. dangerous: I don't see how exactly this would happen. If dbus-launch
> exposes session auth details to everyone, wouldn't that be a bug in D-Bus?

IIRC this was being done on purpose.  I'd have to dig in the list archives to find out more.

But as we're currently hiding the real culprit with the patch for the session bus this doesn't matter anyway.

> Like jpr, I also don't think this is a blocker. Lowering.

Judge it as you want, as soon as I drop the patch for the session bus from D-Bus -- which will happen for Beta 5 if there is no plausible rationale why this is the correct fix -- we're back at zero.

Weelll - to me the solution is not entirely obvious. Clearly some things belong to the 'session' - eg. the X server connection ;-) no-one is arguing that Root should have it's own X server launched I guess. Similarly the session bus is conceptually for that session.
In due course - (as/when the D-BUS re-write is done) I expect a11y to use D/BUS and prolly the session bus to communicate with other applications - as such, we would simple loose application a11y to get there.

The thing that changed here seems to be that gconf is now using the session bus, and expects it to be there (for some reason), and if it is not moans verbosely.

> Therefore any user can gain access to the session bus.

That sounds non-obvious to me. AFAICS the session bus is configured to only allow the owner of the session bus daemon to connect to it. We make a special exception for root (only). So - how is this dangerous ?

Of course - one can imagine that user doing bad things to the app over the session bus (potentially), but similarly one can imagine sending it unexpected X messages too, or doing odd things to it's root window, or simulating key-presses or ...

Why is this any more dangerous than sharing the X connection ? connection auth is done by more than the shared cookie (surely) otherwise there would be no problem in the 1st instance :-)

(In reply to comment #58 from Michael Meeks)

> The thing that changed here seems to be that gconf is now using the session
> bus, and expects it to be there (for some reason), and if it is not moans
> verbosely.

I'd be interested to now the rationale behind "some reason".

> We make a special exception for root (only). So - how is this dangerous ?

Could we please discuss this somewhere else?  It just doesn't belong here.

We have a *new* issues which are not related to policy.

s/now/know

(In reply to comment #57 from Timo Hoenig)
> (In reply to comment #56 from Hans Petter Jansson)

> > Re. wrong: User may want to run programs running as root in his session. We've
> > had plenty of bugs on that previously.

> We never had this reports for 11.0 or earlier.  From my point of view I can
> assure there wasn't a change in D-Bus itself which would cause those *new*
> defects.  We have to look somewhere else.

Well, we've had plenty of bugs on programs running as root in the user's session missing access to elements of said session, like the X display or the session manager.

> The current patch for the session.conf hides the real problem.  That is
> obviously not what we want.
> 
> The real bug is, that the application launched via gnomesu is trying to access
> the session owner's session bus.
> 
> The question is:  Why does it want to access it?

The session bus is an important IPC mechanism for programs in the session. We can't predict all the ways in which it will be used (it looks like in this particular case it's being used to access the user's configuration database).

> I'm in favor of un-setting DBUS_SESSION_BUS_ADDRESS on changing the user with
> gnomesu.  By running anything which changes your identity (su $USER, gnomesu
> $APP, etc.) you're simply out of bounds of the current session.  

It's not that clear-cut. The user needs to run programs as root on its current display, and the display is part of the session. The programs also need to talk to the session manager, e.g. so they can be told to quit when the session closes. There are other requirements, and I think the move to D-Bus as the session IPC mechanism (away from mechanisms like X display properties) will continue.

The ideal fix here would be to adopt a security model that doesn't require you to become a different user in order to accomplish vital tasks - I'd be the first to admit that the "root" security model is broken - but insofar as we have to work within such a security model, we have to take a pragmatic approach.

> > Re. dangerous: I don't see how exactly this would happen. If dbus-launch
> > exposes session auth details to everyone, wouldn't that be a bug in D-Bus?

> IIRC this was being done on purpose.  I'd have to dig in the list archives to
> find out more.

So wouldn't that mean that you can already hijack anyone's session bus? That doesn't stand to reason in my mind. I'm fairly certain a user's session bus is supposed to be secure from other users on the host :)

I'm trimming it to the relevant bits -- please speak up if I was to radical

(In reply to comment #61 from Hans Petter Jansson)

> > The question is:  Why does it want to access it?
> 
> The session bus is an important IPC mechanism for programs in the session. We
> can't predict all the ways in which it will be used (it looks like in this
> particular case it's being used to access the user's configuration database).

This is still *way* to unclear.  Looks like I'll sit down and have a tête-à-tête with the gconf code tomorrow morning.

Before I do so -- do we agree on fixing gconf in case it uses libdbus for something which isn't required?  Otherwise I'll skip that involuntary task.
 
> By running anything which changes your identity (su $USER, gnomesu
> $APP, etc.) you're simply out of bounds of the current session.  
> 
> It's not that clear-cut. The user needs to run programs as root on its current
> display, and the display is part of the session. The programs also need to talk
> to the session manager, e.g. so they can be told to quit when the session
> closes. There are other requirements, and I think the move to D-Bus as the
> session IPC mechanism (away from mechanisms like X display properties) will
> continue.

We're leaving ground -- it's a definition depending on each individuals point of few.

In my opinion the session bus is part of the session and I have yet to see the *functional* requirement that another session needs to access it.  Even if it is the very same user.  Note:  I use the wording 'session' calling 'su' is starting a new one from my point of view.

> The ideal fix here would be to adopt a security model that doesn't require you
> to become a different user in order to accomplish vital tasks

I didn't think that I'd write something like this today in this discussion.  But here it is:  I completely agree.

> - I'd be the first to admit that the "root" security model is broken - but 
> insofar as we have to work within such a security model, we have to take a 
> pragmatic approach.

Well, we have PolicyKit in place.  It seems that it isn't used in our case -- we fail.

> > > Re. dangerous: I don't see how exactly this would happen. If dbus-launch
> > > exposes session auth details to everyone, wouldn't that be a bug in D-Bus?
> 
> > IIRC this was being done on purpose.  I'd have to dig in the list archives to
> > find out more.
> 
> So wouldn't that mean that you can already hijack anyone's session bus? That
> doesn't stand to reason in my mind. I'm fairly certain a user's session bus is
> supposed to be secure from other users on the host :)

No.  Because knowing DBUS_SESSION_BUS_ADDRESS isn't enough.  The session policy forbids another user to connect to it -- and that is, what has been loosen with your patch.

To get things going:

I'll have a look at gconf tomorrow.  If I find something suspicious which we can easily fix I strongly advice to do that.

If this is not the case, we have two options:

1.) Patch gnomesu to nullify DBUS_SESSION_BUS_ADDRESS, remove the patch from D-Bus
2.) Don't patch gnomesu, don't remove the patch from D-Bus

For those two options I'm not willing to judge what we shall do.

I've stated my personal opinion (go for solution 1).

I'm kindly asking anyone involved to express their opinion and have a productive discussion on what is best for SLE11.  Read:  We shouldn't start lengthly discussions on solutions which are not feasible given limited time and limited resources.

Thanks!

> > > > Re. dangerous: I don't see how exactly this would happen.

nor me.
  
> > So wouldn't that mean that you can already hijack anyone's session bus? That
> > doesn't stand to reason in my mind. I'm fairly certain a user's session bus 
> > is supposed to be secure from other users on the host :)
>
> No.  Because knowing DBUS_SESSION_BUS_ADDRESS isn't enough.  The session
> policy forbids another user to connect to it -- and that is, what has been 
> loosen with your patch.

Well - unless I'm mistaken we didn't commit the (frankly silly) <allow user="*" /> but we added the <allow user="root"/> - at least I hope we did.

The latter allows *only* something that could easily happen anyway, and is inside the privilege envelope of the root account anyway. ie. if Root -really- wants to connect to a user's session bus, our advisory security can only stop him so far: he can just gdb to the session bus, tweak the setting & try again if necessary.

ie. AFAICS <allow user="root"/> adds -no- new security hole - beyond this: that applications running as root -might- get a malformed D-BUS message from the session-bus (ie. the user), and -might- then do something bad. Since the user clearly knows the root password anyway - this is something we have to just live with.

So - again; where is the security problem ? I really, really don't see it.

(In reply to comment #64 from Michael Meeks)

> Well - unless I'm mistaken we didn't commit the (frankly silly) <allow user="*"
> /> but we added the <allow user="root"/> - at least I hope we did.

Yes.
 
> The latter allows *only* something that could easily happen anyway, and is
> inside the privilege envelope of the root account anyway. ie. if Root -really-
> wants to connect to a user's session bus, our advisory security can only stop
> him so far: he can just gdb to the session bus, tweak the setting & try again
> if necessary.
> 
> ie. AFAICS <allow user="root"/> adds -no- new security hole - beyond this: that
> applications running as root -might- get a malformed D-BUS message from the
> session-bus (ie. the user), and -might- then do something bad. Since the user
> clearly knows the root password anyway - this is something we have to just live
> with.
> 
> So - again; where is the security problem ? I really, really don't see it.

___I'm not discussing the security or policy issues.___

I've mentioned it before (c.f. comment #59).

Anyway, I'm currently working on finding a fix for the root cause.

First findings:  As expected, we're hiding the real issue with the session bus patch.

- y2cc-g runs as root (gnomsu via slab)
- y2controlcenter-gnome accesses gconf -- fine.  
- it is accessing gconf keys (e.g. /desktop/gnome/applications/main-menu/upgrade_package_command) -- routed to the session owners gconf instance
- bang

Imagine you're doing this twice

- First run starting from session owned by Alice
- Second run starting from session owned by Bob

Depending on $HOME/.gconf/* of Alice and Bob you'll get different results for the gconf key.

Not really what I'd be expecting if I run something as root.

Let me know if I'm missing something -- I'm still working on this by sense of duty -- not profession; unfamiliar fields for someone who's not an gconf/y2cc-g/g* expert.  

> Well - unless I'm mistaken we didn't commit the (frankly silly) <allow user="*"
> /> but we added the <allow user="root"/> - at least I hope we did.

There's no real immediate security problem then.
As Timo pointed having root access the session dbus may have unexpected side effects though. gnomesu really should clean the environment and only pass selected variables through, just like su -.

Created attachment 248649 [details]
The fix.

Following up my words with action -- here's the fix.

I gave it some testing and it didn't fail once.

Please review, please test, please handle with care.  As upstream is probably interested in this, please take care that it gets where it belongs.

Some words on the patch.

Respect the environment.  If DBUS_SESSION_BUS_ADDRESS is set, check whether we can hook ourselves on the referenced bus (dbus_connection_open, dbus_bus_register).  If we fail at the later: unset DBUS_SESSION_BUS_ADDRESS as we're not allowed to utilize this bus.

Enjoy.

Timo - the fix sounds great to me :-) Having said that - when the a11y work moves to d-bus, we will need to re-open root access to the same session bus to make it work I suspect; but that's a problem for 11.2+
Thanks.

Vincent, HPJ is on cert store still, please review patch.

I've dropped the hpj's patch from dbus-1 (osc submit request id 3299).

^- osc submit request id 3302

I've tested the patch and it seems to work fine.

Note that it means that gconf is not used by apps launched as root. This might have some interesting side-effects for the look and feel...

(In reply to comment #73 from Vincent Untz)

> This might have some interesting side-effects for the look and feel...

Please elaborate on this.  I have seen zero difference compared to the previous workaround.

Err, actually, what's the bug we're trying to fix here? Is it "only" something like "do not show an error dialog in yast2?" or something more general? Because the patch only hides the error, and it doesn't change the behavior.

So now I'm not sure we want the patch :-) If we just want to not have an error dialog, we should just not show it in slab/yast. If we want to fix something more general, the patch doesn't help, I believe.

(In reply to comment #75 from Vincent Untz)

> Because the patch only hides the error, and it doesn't change the behavior.

It doesn't hide anything.  Did you understand the patch?

(In reply to comment #76 from Timo Hoenig)
> (In reply to comment #75 from Vincent Untz)
> 
> > Because the patch only hides the error, and it doesn't change the behavior.
> 
> It doesn't hide anything.  Did you understand the patch?

Hrm, my bad. My second test still had the dbus-1 change, so I was not seeing gconfd running as root. Doing too many things at once.

Ive just updated to beta 4, and this problem does not appear. Yet. :-)

Vincent:  OK.  There's a invisible complexity in the patch; involving the auto-launch feature of the D-Bus session bus.  Let me know if you need a verbose version of comment #67.

Laszlo:  Beta 4 ships with the the patch for dbus-session.conf -- no change compared to Beta 3.  You may expect Beta 5 to come a long with the results of this bug.

Beta 5? wow :-D

I've sent the patch upstream (while waiting for my build to finish):
http://bugzilla.gnome.org/show_bug.cgi?id=559273

There's a comment from Havoc there, explaining why he thinks the patch is wrong.

Thanks, will join the discussion there.

OK, so according to the discussion the GConf patch will not be accepted upstream.  Neither does Havoc have another neat solution which would be easy to apply.

This is leaving us the following options:

(1) re-add D-Bus session.conf patch

(+) easy
(-) will not go upstream
(-) hides programming errors (cf. comment 65 and comment 66)
(-) exorbitant as it applies to all session buses started, even if the discussed issue doesn't turn up

(2) add the GConf patch

(+) easy
(+) only kicks in if the discussed issue turns up
(-) will not go upstream

(3) unset DBUS_SESSION_BUS_ADDRESS

(+) easy
(+) doesn't affect any upstream package if we simply run something like "DBUS_SESSION_BUS_ADDRESS gnomesu $APP" from the slab

(4) fix y2controlcenter-gnome and all other applications running via gnomesu -- $APP)

Preface:  Those applications are broken by design.  At least with having PolicyKit in place.  The applications should simply run within the session owners context and gain privileges for specific actions via PolicyKit.

(+) difficult and time consuming
(-) nothing

We're approaching Beta 5.  We should decide on what to do pretty soon, as the check-in deadline is approaching this Friday.

Stefan, this mainly affects the desktop.  Please have a look and state your opinion.  If appropriate, please discuss with Thorsten.  Thanks for your attention.

Let's go with 3). This should affect only the control-center and the slab. And it should be doable until Friday 

*** Bug 438567 has been marked as a duplicate of this bug. ***

(In reply to comment #84 from Stefan Behlert)
> Let's go with 3). This should affect only the control-center and the slab. And
> it should be doable until Friday 

Not sure about this - gnomesu is triggered by X-KDE-SubstituteUID=true, so gnome-cc and main-menu is the wrong spot to fix this.

I missed to mention a sixth solution when doing the summary for comment 83.  (Stefan: that's the one I told you verbally today)

Here it goes:

(6) let gnomesu unset DBUS_SESSION_BUS_ADDRESS

(+) easy
(+) single place to change
(-) probably not accepted upstream (don't know)

This option also popped up in the discussion with Havoc.

Timo: we might want to do this for su, sudo, etc. too. But gnomesu should be enough to fix the specific case of the yast shell.

Vincent, right.  Ludwig could you please comment on this?

I'm also fine to go with 6).

Same here, gnomesu is not really active upstream.

Fine.
Note that "su -" and sudo already clear the environment and only restore variables from a whitelist in the new environment.

Cool, that sounds like a agreement just before we hit the 100+ comments :-)

*** Bug 408317 has been marked as a duplicate of this bug. ***

Ive just updated my system to the latest, and in YAST2 i receive always this message again. :-S

(In reply to comment #87 from Timo Hoenig)
> Here it goes:
> 
> (6) let gnomesu unset DBUS_SESSION_BUS_ADDRESS

Done, submitted to oS:F (#3534).

Patch looks good.  Thanks, Vincent.

*** Bug 443187 has been marked as a duplicate of this bug. ***

Closing bug

Vincent, is this issue completely resolved ? (I can't mark NEEDINFO on a closed bug. So consider this as NEEDINFO)

In SLED11-RC1 as well as openSuSE 11.1, when I login as a normal user, open a terminal, do su (no '-') and open yast2, I still get the error. However if I do 'su -', then I dont get any error on opening yast2. Also no error while opening yast2 from menu.

Please let me know if I should re-open this or there should be separate bug to handle the 'su' case.

(In reply to comment #101 from Rashmi Ranjan Mohanty)
> Vincent, is this issue completely resolved ? (I can't mark NEEDINFO on a closed
> bug. So consider this as NEEDINFO)
> 
> In SLED11-RC1 as well as openSuSE 11.1, when I login as a normal user, open a
> terminal, do su (no '-') and open yast2, I still get the error. However if I do
> 'su -', then I dont get any error on opening yast2. Also no error while opening
> yast2 from menu.

That's expected: "su" will get the error but not "su -". "su" doesn't clear the environment variables.

*** Bug 463994 has been marked as a duplicate of this bug. ***

*** Bug 472656 has been marked as a duplicate of this bug. ***

openSUSE-SU-2012:1418-1: An update that solves 6 vulnerabilities and has 5 fixes is now available.

Category: security (moderate)
Bug References: 381621,394383,428963,432901,437293,443307,503074,697105,707817,743149,783657
CVE References: CVE-2006-6107,CVE-2008-0595,CVE-2008-3834,CVE-2008-4311,CVE-2010-4352,CVE-2012-3524
Sources used:
openSUSE 12.2 (src):    dbus-1-1.5.12-4.10.1, dbus-1-x11-1.5.12-4.10.1
openSUSE 12.1 (src):    dbus-1-1.5.8-2.10.1, dbus-1-x11-1.5.8-2.10.1
openSUSE 11.4 (src):    dbus-1-1.4.1-7.31.1, dbus-1-x11-1.4.1-7.31.1

This is an autogenerated message for OBS integration:
This bug (428963) was mentioned in
https://build.opensuse.org/request/show/3302 Factory / dbus-1
https://build.opensuse.org/request/show/3534 Factory / libgnomesu