On 04/29/2010 05:48 PM, Keith Packard wrote: > Here are a few comments about how I see the new devPrivates scheme > working with XSELinux. Note that the current implementation is > sub-optimal when XSELinux is enabled -- the XSELinux private keys get > initialized late in the game and end up increasing the size of all of > the private records with big chunks of wasted space between their > highest other private index and the XSELinux private index. >
Our mails crossed! I sent a lengthy reply to the original post. > The new privates scheme allows for some of the private keys to remain > 'global', useful in all objects with privates. That's how the old > private implementation worked, so this provides an obvious replication > of that functionality. > > It's not what XSELinux actually needs though. XSELinux uses privates in: > > client > window > pixmap > gc > cursor > colormap > device > extension > selection > property > > It doesn't need privates in > > screen > cursor_bits > dbe_screen > dbe_window > damage > glyph > glyphset > picture > SELinux does use the picture and glyphset privates. Any resource type with a devPrivates field and a registered offset (returned by dixLookupPrivateOffset) gets used in the resource lookup security hook (that gets called from dixLookupResource). I'd like any resource or object that can be named from client-space to have a devPrivates field and a security label. > So, the first obvious optimization is to simply not provide private > space for 'PRIVATE_ALL' in these objects. Renaming this > 'PRIVATE_XSELINUX' might be prudent though. > I guess, although hardcoding that set of object types into the core server doesn't seem ideal. Maybe there could be a way to register a key and then "add" new object types to it, causing the offsets to be recomputed to make it work? > The second optimization should be to sort the PRIVATE_ALL data below > all of the other private data. That way you'll get the shared > PRIVATE_ALL fields first in privates with the per-object data stacked on > top without any gaps. Because we've got pointers to every key, it should > be easy to adjust the offsets when a PRIVATE_ALL key is registered. It's > convenient that XSELinux doesn't need a screen private as that is the > only serious special case in the current privates code. > I think this is the big win. I didn't think it was possible, but if you can fiddle with the offsets to achieve this without affecting the caller I'm all for it. In my other mail I mentioned something about setting aside space at configure time. I still worry about stray objects getting created early in the initialization sequence before everything has had a chance to register. > Finally, the subjectKey is only needed in clients and devices, and in > each case the XSELinux code knows which object it is dealing with. So, > creating separate keys for each of those objects would save space in all > of the other objects. > Agreed. > With those changes, the XSELinux privates should be more efficient than > they are today. > > However, it seems like someone who can actually run the code should be > involved in the process. Should I code some stuff up and let others get > it working? Or just sit around waiting for someone else to submit fixes? > I will test as needed and change the SELinux code as required. -- Eamon Walsh National Security Agency _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
