RE: file(1)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Russell Coker [mailto:russell@xxxxxxxxxxxx] 
> Sent: Friday, March 28, 2008 11:18 PM
> To: Joshua Brindle
> Cc: Stephen Smalley; SE-Linux
> Subject: Re: file(1)
> 
> On Saturday 29 March 2008 12:55, "Joshua Brindle" 
> <jbrindle@xxxxxxxxxx> wrote:
> > > <jbrindle@xxxxxxxxxx> wrote:
> > > > Which is fine, but it just won't be useful for future modules.
> > >
> > > Would it be possible to try and make things work well with
> > > file(1) when designing future module formats?  Little things like 
> > > zero terminating strings really help.
> >
> > We want modules to be user editable using standard editors so no 
> > binary data will be used..
> 
> So we are back to editing source?  That's fine by me.
> 

Yes, but with the infrastructure to link in modules, etc. Source just
makes it much easier to manage the modules from the user perspective.

> > Unless file will be able to find the first non-comment line I'm not 
> > sure how it'll work.
> 
> It seems to work fine for many other text files.  Also there 
> is nothing preventing the creator of a text file format from 
> specifying that the first line must contain some specific 
> text indicating the format.  It probably would be good if the 
> compiler (loader, linker, semanage, whatever you call
> it) could recognise something that might be suitable input.  
> If it could give a specific error that it's operating on 
> something it considers not to be a suitable source file it 
> would help cover some common error cases.
> 
> $ file src/*
> src/Makefile:      ASCII make commands text
> src/dso.h:         ASCII C program text
> src/mcstrans.c:    ASCII C program text
> src/mcstrans.init: Bourne-Again shell script text executable
> src/mcstransd.c:   ASCII C program text
> 
> The above is the file(1) output for some common file types.  
> It seems to work quite well for them.
> 
> Below are some quick magic entries I hacked up for SE Linux 
> policy source.  
> I'm not sure at this stage whether I should submit them for 
> inclusion.  But they do demonstrate what can be done with 
> recognising text files.
> 
> 0       string  policy_module(  SE Linux policy module source
> 1       string  policy_module(  SE Linux policy module source
> 2       string  policy_module(  SE Linux policy module source
> 
> 0       string ##\ <summary>    SE Linux policy interface source
> 
> 0       search  gen_context(    SE Linux policy file contexts
> 

One thing, there won't be separate files for interfaces, modules, and
file contexts anymore (at least from the toolchain perspective,
refpolicy might keep them separate internally)

So modules will be self contained source files with everything
necessary.

I wouldn't submit anything yet, a lot of the refpolicy things are slated
to become parts of the proper language and the way modules are going to
look haven't been completely hammered down.


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

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux