On 22-Nov-2002 Robert Watson wrote:
>
> On Thu, 21 Nov 2002, Luigi Rizzo wrote:
>
>> [Bcc to -net because it is relevant there. This email has been triggered
>> by a private discussion i was having with other committers (who will
>> easily recognise themselves :) which suggested the possibility of adding
>> more fields to mbuf headers]
>>
>> Just recently came up to my attention that we have the following code in
>> <sys/_label.h>
>>
>> #define MAC_MAX_POLICIES 4
>> struct label {
>> int l_flags;
>> union {
>> void *l_ptr;
>> long l_long;
>> } l_perpolicy[MAC_MAX_POLICIES];
>> };
>>
>> (what are l_perpolicy[], ints ? Could this be written a bit better ?)
>> and then in <sys/mbuf.h>
>
> MAC labels provide general purpose security label storage across a variety
> of kernel objects. Each MAC label is made up of a number of "slots" which
> are allocated to statically linked or dynamically loaded policies. The
> union is used to allow policies to use their slot for either the purposes
> of an integer store, or as a pointer with the semantics they define. Some
> policies simply use the long to represent their policy information,
> perhaps by itself (a partition number), or to key into an existing array.
> Other policies use the pointer to point to shared reference-counted,
> static, or per-label data. Probably the "long" should be changed to some
> other integer type that better matches the notion of pointer length.
intptr_t.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
