Re: [POLICYREP] [RFC/PATCH 2/3] policy package implementation

[Joshua Brindle <method@manicmethod.com>]

Karl MacMillan wrote:
>
>>  This first patch I was trying to keep it dead 
>> simple by not even requiring a custom packager and instead just using 
>> xar CLI. If we want to use more sophisticated things in xar (like 
>> per-file attributes) we'd need something custom. Even if we just make a 
>> subdocument (which is archive-wide in scope) and add some selinux bits 
>> to it like policy name that can still be done with the CLI.
>>
>> xar -xf foo.xar will unpackage it
>>     
>
> Ok - then I vote for a custom packaging tool. If nothing else it can
> retain some similarity to the current tool syntax.
>
>   
Ok, I'll go ahead and do that for the next version of the patches. We 
are basically taking a standard archive format and one-offing it, 
fortunately the format supports that kind of thing so we can continue 
using all their library infrastructure, which is a huge win over what we 
are doing now.

> [..]
>
>   
>>>>>   
>>>>>       
>>>>>           
>>>> There is no module_read function right now so thats just a placeholder.
>>>>
>>>>     
>>>>         
>>> There is if the module is source :)
>>>
>>>   
>>>       
>> nak.
>>     
>
> Why? Last time we discussed it you wanted support for storing additional
> information but the only examples that you had were original filename
> and line number. This is already supported (it has to be for the M4
> processing). So what else? If nothing else, why have an additional
> format?
>   

It doesn't seem reasonable to essentially reproduce the m4 preprocessing 
statements just to keep a single parser. just look at a preprocessed 
module and see how nasty it looks:

#line 156537 "tmp/all_interfaces.conf"
       
#line 1 "policy/modules/services/sendmail.te"

       
#line 2
      
#line 2
                module sendmail 1.3.1;
#line 2

#line 2
                require {
#line 2
                        role system_r;
#line 2


That isn't exactly what I had in mind when I said we'd want to store 
extra info. We'd also have to add parser support for that mess to the 
source parser, non-ideal I think when we can path the data in something 
easily readable (by machine) without loads of junk that isn't necessary.


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