Re: New ideas on implementation on libsetrans.

[Daniel J Walsh <dwalsh@redhat.com>]

Stephen Smalley wrote:

>On Tue, 2005-09-13 at 16:04 -0400, Daniel J Walsh wrote:
>  
>
>>Most of the people I talk to in Red Hat don't like alternatives.    We 
>>can change to just use libsetrans and implement to communication in this 
>>library, but I don't see that as adding much value.
>>    
>>
>
>The advantage of putting the communication/caching code into a separate
>library (libsetrans) rather than into libselinux directly are:
>- it leaves open the option of omitting the code for the communications
>and caching altogether for systems that have no need for label
>translation,
>  
>
If no one is listening on  the socket or the socket does not exist you 
get the same behavior.

>- it leaves open the option of providing a libsetrans implementation
>that deals with flat files directly rather than communicating over a
>socket.
>
>The only disadvantage that I see is that users of the static libselinux
>don't get the translation by default; they have to explicitly link with
>libsetrans themselves and invoke the translation interfaces if they want
>translation.  But such users should be very few and manageable.  prelink
>doesn't truly need translation; it just needs getfilecon to always
>return a context that can be used in a subsequent setfilecon call, and
>James' kernel patch addresses that concern.
>
>  
>
I see packaging problems and requiring objects to link with -dl.  We are 
basically looking at a packaging problem
now, which is why we are bringing this up. 

I have added Nalin to the message to get his comments.

>Am I missing other disadvantages?
> 
>  
>


-- 



--
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.