On Thu, 29 Apr 2010 21:37:18 -0400, Eamon Walsh <[email protected]> wrote:
> Our mails crossed! I sent a lengthy reply to the original post. Perfect! > 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). That's fine -- the current implementation sticks a private everywhere for PRIVATE_ALL just like the existing code. But, with the new code actually allocating all of the privates, it seems prudent to avoid sticking XSELinux stuff in objects that just don't need them. > I'd like any resource or object that can be named from client-space to > have a devPrivates field and a security label. Yup. I wish we could stick this in the resource database, but I don't think it's workable. > I guess, although hardcoding that set of object types into the core > server doesn't seem ideal. I'm trying not to write code we don't actually need, although the API would make it easy to add this. Just add an API to register a new private type and make the existing array resizeable. > 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? No offsets would need recomputing; the only fixed part of the implementation is the array of pointers to lists of private keys. > 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. We've got pointers to every key in the system, walking them and updating them will be easy. > I still worry about stray objects getting created early in the > initialization sequence before everything has had a chance to > register. The code has big 'assert's all over it that will catch any mistakes here; Tiago Vignetti already found one related to colormaps on multiple screens. I've fixed that by getting the associated key registered earlier, but colormaps may come back to haunt us again as the default colormap is created during screen initialization. I suspect I'll need a kludge for the default colormap; it may just be that I need to go and find it and reallocate it on the fly. > I will test as needed and change the SELinux code as required. Would you like me to try and rework the PRIVATE_ALL stuff to move them to the start of the list? With that change, I think the remaining suggestions were entirely within the XSELinux implementation. -- [email protected]
pgplbqgtV1z0T.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
