From: Daniel Mack
A connection chooses which metadata it wants to have attached to each
message it receives with kdbus_cmd_hello.attach_flags. The metadata
will be attached as items to the messages. All metadata refers to
information about the sending task at sending time, unless otherwise
stated
From: Daniel Mack
A connection chooses which metadata it wants to have attached to each
message it receives with kdbus_cmd_hello.attach_flags. The metadata
will be attached as items to the messages. All metadata refers to
information about the sending task at sending time, unless otherwise
stated
On Mon, Dec 1, 2014 at 5:50 AM, Daniel Mack wrote:
> Hi Andy,
>
> Sorry for the late response.
>
> On 11/21/2014 08:50 PM, Andy Lutomirski wrote:
>>> +static int kdbus_meta_append_cred(struct kdbus_meta *meta,
>>> + const struct kdbus_domain *domain)
>>> +{
>>> +st
Hi Andy,
Sorry for the late response.
On 11/21/2014 08:50 PM, Andy Lutomirski wrote:
>> +static int kdbus_meta_append_cred(struct kdbus_meta *meta,
>> + const struct kdbus_domain *domain)
>> +{
>> +struct kdbus_creds creds = {
>> +.uid = from_kuid_mung
On 11/20/2014 09:02 PM, Greg Kroah-Hartman wrote:
> From: Daniel Mack
>
> A connection chooses which metadata it wants to have attached to each
> message it receives with kdbus_cmd_hello.attach_flags. The metadata
> will be attached as items to the messages. All metadata refers to
> information a
From: Daniel Mack
A connection chooses which metadata it wants to have attached to each
message it receives with kdbus_cmd_hello.attach_flags. The metadata
will be attached as items to the messages. All metadata refers to
information about the sending task at sending time, unless otherwise
stated
On Mon, Nov 3, 2014 at 4:00 AM, Simon McVittie
wrote:
> On 01/11/14 16:19, Andy Lutomirski wrote:
>> You can't justify logging fundamentally unverifiable things like the
>> command line by saying that you want to know if someone tries to play
>> (impossible-to-reliably-detect) games to obscure the
On 01/11/14 16:19, Andy Lutomirski wrote:
> You can't justify logging fundamentally unverifiable things like the
> command line by saying that you want to know if someone tries to play
> (impossible-to-reliably-detect) games to obscure their command line.
I think kdbus might be mixing up two ortho
On Sat, Nov 1, 2014 at 4:05 AM, Daniel Mack wrote:
> Hi Andy,
>
> On 10/30/2014 10:01 PM, Andy Lutomirski wrote:
>> On Thu, Oct 30, 2014 at 8:54 AM, Daniel Mack wrote:
>
>>> We merely allow user that are connected to a bus to query the
>>> credentials of the creator of the bus they're connected t
Hi Andy,
On 10/30/2014 10:01 PM, Andy Lutomirski wrote:
> On Thu, Oct 30, 2014 at 8:54 AM, Daniel Mack wrote:
>> We merely allow user that are connected to a bus to query the
>> credentials of the creator of the bus they're connected to.
>
> Why do you allow this? What purpose does it serve?
On Thu, Oct 30, 2014 at 8:54 AM, Daniel Mack wrote:
> On 10/30/2014 03:07 PM, Andy Lutomirski wrote:
>> On Thu, Oct 30, 2014 at 1:45 AM, Daniel Mack wrote:
>>> 2. When a new bus is created through KDBUS_CMD_BUS_MAKE, so peers can
>>> later query the credentials of the owner of the bus they're con
On 10/30/2014 03:07 PM, Andy Lutomirski wrote:
> On Thu, Oct 30, 2014 at 1:45 AM, Daniel Mack wrote:
>>
>> 1. At open() time, So we can tell peers (through KDBUS_CMD_CONN_INFO)
>> about the credentials a connection had when it was created with
>> KDBUS_CMD_HELLO.
>
> Then the API that tells peers
On Thu, Oct 30, 2014 at 1:45 AM, Daniel Mack wrote:
>
> 1. At open() time, So we can tell peers (through KDBUS_CMD_CONN_INFO)
> about the credentials a connection had when it was created with
> KDBUS_CMD_HELLO.
Then the API that tells peers about this information needs to make
this very clear.
>
On 10/30/2014 01:13 AM, Andy Lutomirski wrote:
> On Wed, Oct 29, 2014 at 3:33 PM, Andy Lutomirski wrote:
>> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>> wrote:
>>> From: Daniel Mack
>>>
>>> A connection chooses which metadata it wants to have attached to each
>>> message it receives wi
On 10/29/2014 11:33 PM, Andy Lutomirski wrote:
> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
>> +/**
>> + * kdbus_meta_new() - create new metadata object
>> + * @meta: New metadata object
>> + *
>> + * Return: 0 on success, negative errno on failure.
>> + */
>> +int kdbus_meta
On Wed, Oct 29, 2014 at 3:33 PM, Andy Lutomirski wrote:
> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
> wrote:
>> From: Daniel Mack
>>
>> A connection chooses which metadata it wants to have attached to each
>> message it receives with kdbus_cmd_hello.attach_flags. The metadata
>> will b
On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman
wrote:
> From: Daniel Mack
>
> A connection chooses which metadata it wants to have attached to each
> message it receives with kdbus_cmd_hello.attach_flags. The metadata
> will be attached as items to the messages. All metadata refers to
> info
From: Daniel Mack
A connection chooses which metadata it wants to have attached to each
message it receives with kdbus_cmd_hello.attach_flags. The metadata
will be attached as items to the messages. All metadata refers to
information about the sending task at sending time, unless otherwise
stated
18 matches
Mail list logo
