RE: file(1)

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

 



Stephen Smalley wrote:
> On Thu, 2008-03-27 at 23:49 +1100, Russell Coker wrote:
>> # SE Linux policy modules *.pp
>> 0       lelong  0xf97cff8f      SE Linux modular policy
>>> 4      lelong  x       version %d,
>>> 8      lelong  x       %d sections,
>>>> (12.l) lelong 0xf97cff8d
>>>>> (12.l+27) lelong x           mod version %d,
>>>>> (12.l+31) lelong 0           Not MLS,
>>>>> (12.l+31) lelong 1           MLS,
>>>>> (12.l+23) lelong 2
>>>>>> (12.l+47) string >\0        module name %s
>>>>> (12.l+23) lelong 1          base
>> 
>> The above /etc/magic entry allows file(1) to display some information
>> about policy modules.  Below is a sample of the result:
>> 
>> # file qmail.pp  base.pp  /tmp/loadkeys.pp
>> qmail.pp:         SE Linux modular policy version 1, 2 sections, mod
>> version 7, Not MLS, module name qmail\005

Also I think SELinux policy package, this magic number is for packages,
modules have their own magic number.

>> base.pp:          SE Linux modular policy version 1, 4 sections, mod
>> version 7, Not MLS, base /tmp/loadkeys.pp: SE Linux modular policy
>> version 1, 2 sections, mod version 6, MLS, module name loadkeys\005
>> 
>> Please let me know what you think of this, in terms of text
>> formatting, information displayed, and use of file(1) features.
> 
> "policy version 1" ought to be "policy type 1", or more
> simply, "base module" (1) or "non-base module" (2).
> 
> Just for comparison with the existing support in file for
> kernel policies, "file policy.21" displays:
> policy.21: SE Linux policy v21 8 symbols 7 ocons
> 
> Not sure though that the symbols and ocons info is helpful
> there to users, and it should always be implicit from the version.
> 
> Note btw that this format is expected to be obsoleted by the
> policyrep work. 
> 
>> The \005 after the module name is due to the fact that file(1) seems
>> to support only two types of string, a "C string" (terminated by \0)
>> and a "Pascal string" where a single byte is used to indicate the
>> length.  Using a 32bit little-endian word to indicate the length
>> doesn't seem to work with file(1) - but if anyone can figure out a
>> way then please let me know. 
>> 
>> It seems to me that it would be a good idea to write /etc/magic
>> entries at the same time as devising file formats.  Being able to
>> quickly and easily determine the contents of a file is a really handy
>> feature.  Working with the limitations of file(1) to support this to
>> the greatest degree possible would be a good thing.  If the module
>> name was limited to 255 characters I doubt that it would ever
>> inconvenience anyone (in the past I've used compilers that support
>> symbol lengths of ~30 characters), but having a better display in
>> file(1) output would often help people.  Another option would be to
>> have a word indicating the string length while also having a 0
>> terminator (wasting the occasional byte isn't really a problem).



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