I selected operation because it is not ioctl specific. Stephen and I
had discussed the possibility of this being used for other things but
ultimately decided to focus on ioctls because that was my intended
use-case. I would be ok with other names, but I also thing the naming
could be kept the same and I could add clearer in-code comments to
better convey the extended operations or extended permissions idea.
On Thu, May 21, 2015 at 7:39 AM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> On Thu, May 21, 2015 at 10:22 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
>> On 05/21/2015 10:16 AM, Paul Moore wrote:
>>> On Thu, May 21, 2015 at 8:33 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
>>>> On 05/20/2015 05:22 PM, Paul Moore wrote:
>>>>>> @@ -64,6 +66,16 @@ struct avc_cache {
>>>>>> u32 latest_notif; /* latest revocation notification */
>>>>>> };
>>>>>>
>>>>>> +struct avc_operation_decision_node {
>>>>>> + struct operation_decision od;
>>>>>> + struct list_head od_list;
>>>>>> +};
>>>>>
>>>>> Making this more generic may mean adding an extra field here to specify the
>>>>> type of extension, e.g. ioctl commands.
>>>>>
>>>>>> +struct avc_operation_node {
>>>>>> + struct operation ops;
>>>>>> + struct list_head od_head; /* list of operation_decision_node */
>>>>>> +};
>>>>>
>>>>> As mentioned earlier, I think "operation" needs a name change; I tend to like
>>>>> "extop" better, e.g. "avc_extop_decision_node" and "avc_extop_node". Feel
>>>>> free to suggest others.
>>>>>
>>>>> The "operation" struct is named poorly as well; even if we stick with
>>>>> "operation" elsewhere we really need to name this one better, it's way too
>>>>> generic.
>>>>
>>>> Don't want to bikeshed here, but I think "operation" is more readable
>>>> then "extop" (not evident what that means or even whether it is supposed
>>>> to be read as "ex-top" or "ext-op" or what). "operation" at least is
>>>> meaningful and is a suitable generalization of "ioctl command".
>>>
>>> I agree we're (okay, me) being a bit nitpicky here regarding names,
>>> but I really don't like "operation". I'd much prefer if we could find
>>> something else that implies an extension to the existing 32
>>> permissions, maybe "extperm" or similar?
>>>
>>> As I said earlier, I'm open to suggestions so long as they aren't "operation" :)
>>
>> Well, let 's see what these values could possibly represent. Presently
>> they are "ioctl commands". "Netlink message types" are a possible use
>> case. System call numbers would be a closer analogy than permissions,
>> as effectively this is a one-to-one mapping for kernel operations (oh,
>> whoops, there is that word again), so if we were doing this for normal
>> permission checking, we would be encoding the system call number instead.
>
> :)
>
>> Now, what word can be used to describe all of those things? I have no
>> idea. Operation seemed pretty close to me.
>
> How about you Jeff, any ideas?
>
> --
> paul moore
> www.paul-moore.com
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
