#4377 NORM Never A: Merge secured DBus name binding into build

Zarro Boogs per Child bugtracker at laptop.org
Mon Oct 22 07:08:51 EDT 2007


#4377: Merge secured DBus name binding into build
------------------------+---------------------------------------------------
 Reporter:  coderanger  |       Owner:  marco         
     Type:  task        |      Status:  new           
 Priority:  normal      |   Milestone:  Never Assigned
Component:  security    |     Version:                
 Keywords:              |    Verified:  0             
------------------------+---------------------------------------------------
 {{{
 neuralis:
 can you give me a brief status report on where we are with the dbus patch
 that lets us read and authenticate binding services by socket peer xid?

 coderanger:
 It works fine and does indeed communicate with Rainbow (where all the
 policy gibberish stays)

 neuralis:
 so the only thing it needs is to be put into the build?

 coderanger:
 Havoc had some largely stylistic concerns about upstreaming the patch, and
 I just haven't had time to go back to it

 coderanger:
 Yeah, I was working against dbus head, so I haven't tried applying it to
 whichever release+patches we are using now

 neuralis:
 any chance you can look at that in the next day or so?

 coderanger:
 Unlikely, I've got a huge chunk of work due on wednesday

 neuralis:
 crapsicles. okay, can you point me at the patches and anything else i
 need?

 coderanger:
 the dbus folder in the security tree should be a full CVS checkout with my
 changes in place

 coderanger:
 So just run cvs diff, and try adding the patches to whatever RPM we are
 using now

 neuralis:
 bokay. once you build a dbus with the changes, what happens? anything i
 need to know about activating the functionality? how does it identify
 rainbow? etc

 coderanger:
 The service name and such are currently hardcoded.

 neuralis:
 right, i mean, rainbow itself has to bind to a service name without that
 getting proxied out to rainbow for a policy decision

 neuralis:
 how is the bootstrapping handled?

 coderanger:
 I also have some modified dbus spec files in learn:fedora/dbus/OLPC-2

 coderanger:
 The modified behavior should only ever be active on the session bus

 coderanger:
 rainbow is a system service

 coderanger:
 the system bus is already controlled by the dbus policy files

 neuralis:
 ok, so the modified dbus chages the semantics of binding to a service name
 on the session bus such that all bind requests are passed to rainbow,
 which sits on the system bus, for a policy decision. is that an accurate
 description?

 coderanger:
 yes


 coderanger:
 of course a simple if could be added to allow for bootstraping on system
 bus, I just didn't see a reason


 coderanger:
 To activate it in the session bus I think you needed to add
 "<olpc>on</olpc>" to the session bus config file
 }}}

-- 
Ticket URL: <https://dev.laptop.org/ticket/4377>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system



More information about the Bugs mailing list