Re: [POLICYREP PATCH] Add generic iterators and a list data type to libsepol

[Karl MacMillan <kmacmillan@mentalrootkit.com>]

On Mon, 2007-04-23 at 13:52 -0400, Stephen Smalley wrote:
> On Mon, 2007-04-23 at 12:28 -0400, James Antill wrote:
> > On Mon, 2007-04-23 at 11:48 -0400, Karl MacMillan wrote:
> > 
> > > Glib, on the other hand, would provide everything that we need. In fact,
> > > gobject is a perfect fit for the policy object abstraction that I
> > > created with many advantages (including support for exporting the
> > > objects to other languages like python).
> > > 
> > > The Pros of using glib:
> > > * All the data structures that we need.
> > > * Better tested foundation.
> > > * Safe string functions.
> > > * Familiar environment for many developers.
> > > * Complete object-oriented layer for the policy rep.
> > > * Easy export to Python and other languages.
> > > * Our code gets much smaller (libsemanage in particular could shrink if
> > > we used glib).
> > > 
> > > The Cons:
> > > * Large dependency.
> > > * Potential security issues in glib (not certain this is a real issue,
> > > but glib is fairly big).
> > > * Glib tends to be slightly verbose and boilerplate heavy.
> > 
> >  I'm pretty sure glib is used in a few security relevant places, so I
> > doubt that's a problem. The "dependency" argument just seems like normal
> > C programmer twitchyness ... glib is at least as portable as what we'd
> > use it in and is included in pretty much every distro.
> > 
> >  The only real problem I've ever had with glib is that calling g_new()
> > calls abort() on failure (and by extension so does everything that
> > allocates in glib).
> >  This also tends to mean that glib code allocates much more freely than
> > normal C code. But if you can swallow the allocation death pill, it's
> > hard to argue against glib ... IMO.
> 
> I can't swallow the allocation death pill - how does one perform sane
> cleanup with such behavior?

To be fair, in libsepol we currently just exist on allocation error.
Yes, it's better than abort, but we don't really have a need to perform
cleanup.

libsemanage is obviously different and I don't think the libsemanage
dependency on libsepol is ever going to be removed.

>   However, looking around, I see you can
> replace the allocator virtual table with your own functions and there
> are g_try_* functions that return NULL rather than calling abort.  But
> not clear that helps with its own internal usage of g_new.
> 

This does help internal usage of g_new (verified by code inspection and
experimentation). However, glib includes several custom allocators and
replacing the allocator vtable did not seem to help there. It might be
possible to track down all of the allocators and convince them not to
abort, but there may be problems in the future. We could also try
catching sigabort but there would be no good way to figure out why the
abort was delivered. This is really frustrating and is causing people to
not use glib (the X hackers rejected it over this reason).

Any other options (there don't seem to be any obvious ones)? Personally,
I vote for the C++ STL but that requires a small change to which some
might object. In summary - C sucks and I'm tired of this 1980s
programming environment.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.