Re: policyrep questions

On Wed, 2007-05-09 at 11:29 -0400, Stephen Smalley wrote:
> On Tue, 2007-05-08 at 18:29 -0400, Karl MacMillan wrote:
> > I have a few questions as I continue to do the policyrep patches.
> >
> > 1) The free functions for the objects may need to return an error (which
> > I hate, but there is no good way to avoid this). This will break
> > compatibility with the existing string based sepol objects (like
> > sepol_bool). Any problems breaking this compatibility?
>
> Not a problem (.so version has already changed in -policyrep and we have
> already made other incompatible changes).
>
> OTOH, what could/would a caller do if a free function failed?

It's not clear - it will be _very_ hard to guarantee that the data structures are in some sort of semi-valid state so that the free function could be called again.

> At that
> point, it will leak memory unless it aborts altogether, right? So
> possibly we gain nothing from returning an error status to the caller?

Basically - the worst case is a leak. And bear in mind, this is a failure case caused by the inability to allocate a couple of bytes. Chances are we are about to hit many other unrecoverable errors.

To make this worse - there are several cases where I ignore failures in free functions. In error paths that free an object I usually want to return the original error and not the error on free - so I ignore the return from the free functions.

> What do other libraries do under similar conditions? Or do they avoid
> it through different data structure and API design?
>

No idea. It is hard to fully encapsulate all structs and avoid this issue I think. Even if I made it so that the library could internally put all of the structs on the stack users of the library would be faced with exactly the same set of issues.

I vote to suppress all of these free errors (which don't occur often - most of these functions have error returns just for the consistency that is needed for the object system).

>
> > 4) We assume NULL-terminated strings all over the place - should we be
> > providing apis with length? Alternatively, should we provide a better
> > string object (since we are currently re-inventing the wheel, why not?).
> > We could pull in something like James Antills Vstr library -
> > http://www.and.org/vstr/ (read and be amazed at the diligence of James).
> > It just seems crazy that our apis are not the safest.
>
> I'm not clear that tracking length separately is advantageous for these
> APIs.

It might be more efficient in many cases. Obviously we can't protect against malicious callers, but forcing people to pass length makes them aware of the issues I think.

> What specific advantages would accrue to libsepol from using
> vstr?

We are going to start wanting to build up some complex strings as part of the policyrep work. That kind of concatenation is painful with the C string APIS (and inefficient). Vstr is also designed to be easy / efficient to use to push strings across the network.

> What is the cost (incl. dependencies)?
>

I don't think there are any deps. It's not in fedora yet, but it will be soon.

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.