5:32 p.m.
Following email about context filtering in GUPnP, see message
<https://mail.gnome.org/archives/gupnp-list/2013-June/msg00011.html>
What would be the impacts on dLeyna?
There will be more development for this component.
First, there will be a white list by servers using GUPnP, that means one
for dleyna-server and one for dleyna-renderer.
That implies all applications using the same dLeyna component (server or
renderer) will share the same white list.
We need to provide APIs, so applications could manage their own white list.
We need also to provide a signal, so applications using the same dLeyna
component, will be warned when another application is making change to
the white list.
How to manage the white list?
dLeyna won't store any white list. It will just provide APIs, so
applications are going to be able to manage their own white list.
dLeyna won't provide a default white list, nor store a default white
list in its preferences.
dLeyna dbus API:
interface: com.intel.dLeynaServer.Manager
Methods:
WhiteListEnable(b enable) -> void
WhiteListAddInterface(s interface) -> b
WhiteListRemoveInterface(s interface) -> b
WhiteListGetInterface() -> as
WhiteListResetInterface() -> void
s interface: a semi colon separated string list
Signal:
WhiteListChanged(s)
Return the list of interface currently in the white list.
interface: a semi colon separated string list
Property:
WhiteListEnabled -> b (read only)
Any comments are welcome.
Thanks,
Ludovic
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
2:14 p.m.
Hi Ludo,
In general it looks good to me. I have a few comments, inline
On 06/27/2013 06:32 PM, Ludovic Ferrandis wrote:
Following email about context filtering in GUPnP, see message
<https://mail.gnome.org/archives/gupnp-list/2013-June/msg00011.html>
What would be the impacts on dLeyna?
There will be more development for this component.
First, there will be a white list by servers using GUPnP, that means one
for dleyna-server and one for dleyna-renderer.
That implies all applications using the same dLeyna component (server or
renderer) will share the same white list.
We need to provide APIs, so applications could manage their own white list.
We need also to provide a signal, so applications using the same dLeyna
component, will be warned when another application is making change to
the white list.
How to manage the white list?
dLeyna won't store any white list. It will just provide APIs, so
applications are going to be able to manage their own white list.
dLeyna won't provide a default white list, nor store a default white
list in its preferences.
Actually, I was thinking that the dLeyna components should store the
whitelist. As there is only really one whitelist per dLeyna service it
doesn't really make sense to require applications to manage these lists
as they don't have much control over them. I think this will lead to
confusion, e.g., the act of launching application A modifies the
security settings of the already running application B.
So, my feeling was the dLeyna services would store the whitelists and
that the the APIs below would be used by a single settings application
and not by individual dLeyna applications. This way there will be no
confusion. The same settings application could provide the
corresponding settings for the DMS and the DMR, so all your DLNA
security settings would be localised in a single place.
dLeyna dbus API:
interface: com.intel.dLeynaServer.Manager
Methods:
WhiteListEnable(b enable) -> void
WhiteListAddInterface(s interface) -> b
WhiteListRemoveInterface(s interface) -> b
WhiteListGetInterface() -> as
WhiteListResetInterface() -> void
From the point of view of a settings dialog, it's probably easier if
there is a method that allows the whitelist to be replaced in one go,
e.g., WhiteListSet(as interfaces).
Also, what happens if WhiteListEnable(True) has been called and then we
call this WhiteListResetInterface? Does it mean we can't see any UPnP
devices? Calling this method followed by WhiteListAddInterface might
not be very efficient as it might result in us losing contexts and then
regaining them, i.e., DMSs might disappear and then re-appear.
So having said all this, my feeling is that something like
WhiteListSet(as interfaces) -> void
would be better than
WhiteListAddInterface(s interface) -> b
WhiteListRemoveInterface(s interface) -> b
WhiteListResetInterface() -> void
Internally, dLeyna can translate WhiteListSet into the appropriate
whitelist_add and remove calls.
WhiteListGetInterface() -> as
This should probably be WhiteListGetInterfaces, right? What does this
return? The list of interfaces in the whitelist or the list of current
active interfaces on the device. If it's the former, how does the
application work out work what values it can pass to
WhiteListAddInterface? Does it need to go to the network manager to
retrieve this information? Is there any way we could provide a
convenience method that would allow applications to easily retrieve this
information?
Regards,
Mark
3:35 p.m.
Hi Mark,
On 03/07/2013 15:14, Mark Ryan wrote:
Hi Ludo,
In general it looks good to me. I have a few comments, inline
On 06/27/2013 06:32 PM, Ludovic Ferrandis wrote:
> Following email about context filtering in GUPnP, see message
> <https://mail.gnome.org/archives/gupnp-list/2013-June/msg00011.html>
>
> What would be the impacts on dLeyna?
> There will be more development for this component.
> First, there will be a white list by servers using GUPnP, that means one
> for dleyna-server and one for dleyna-renderer.
> That implies all applications using the same dLeyna component (server or
> renderer) will share the same white list.
>
> We need to provide APIs, so applications could manage their own white
> list.
> We need also to provide a signal, so applications using the same dLeyna
> component, will be warned when another application is making change to
> the white list.
>
>
> How to manage the white list?
>
> dLeyna won't store any white list. It will just provide APIs, so
> applications are going to be able to manage their own white list.
> dLeyna won't provide a default white list, nor store a default white
> list in its preferences.
>
Actually, I was thinking that the dLeyna components should store the
whitelist. As there is only really one whitelist per dLeyna service it
doesn't really make sense to require applications to manage these lists
as they don't have much control over them. I think this will lead to
confusion, e.g., the act of launching application A modifies the
security settings of the already running application B.
There are pro & cons to each solution.
It depends where you want to manage this list of entries.
In your solution, the list should be managed (to be user friendly) by a
dleyna settings application, that doesn't exist for instance.
That means also, no API to modify the list of entries. Only dLeyna is
authorized to modify it.
It could be done this way. It simplifies applications, but add more
complexity to dLeyna.
So, my feeling was the dLeyna services would store the whitelists
and
that the the APIs below would be used by a single settings application
and not by individual dLeyna applications. This way there will be no
confusion. The same settings application could provide the
corresponding settings for the DMS and the DMR, so all your DLNA
security settings would be localised in a single place.
As I explain in my first email, there are 2 solutions to store the
whitelist.
The first one, is to use the existing settings files, the second one is
to manage another settings file for whitelist.
In the first solution, the main advantage is that we already monitor the
settings file. We just need to add a new entry in the file.
The main inconvenience, is that potentially, we won't have the same
settings for the DMS & DMR.
Is it really a problem?
Another good point, the dLeyna Settings application will manage only 2
files.
The second solution is to manage another settings file only for the
whitelist.
We could have a common settings for server & renderer or a separate one.
The main inconvenience is that we should monitors 2 settings files. (But
we already have the code for that.)
>
> dLeyna dbus API:
>
> interface: com.intel.dLeynaServer.Manager
>
> Methods:
>
> WhiteListEnable(b enable) -> void
> WhiteListAddInterface(s interface) -> b
> WhiteListRemoveInterface(s interface) -> b
> WhiteListGetInterface() -> as
> WhiteListResetInterface() -> void
>
At this point, I should mention that API should be renamed to follow
GUPnP naming, and replace 'interface' by 'entry'.
It's more accurate, as 'entry' could be an interface (eth,..), a SSID,
an IP address, etc...
And it's less confusing.
From the point of view of a settings dialog, it's probably
easier if
there is a method that allows the whitelist to be replaced in one go,
e.g., WhiteListSet(as interfaces).
2 points:
- There won't be dLeyna interface to modify the whitelist. It's an entry
in a settings file. To update the settings, the application will use
GLib API.
- If we manage the WL in dLeyna, there won't be any public API (except
the one discussed below), as dLeyna will call GUPnP API, but application
have nothing to do.
Also, what happens if WhiteListEnable(True) has been called and then
we
call this WhiteListResetInterface? Does it mean we can't see any UPnP
devices?
It's the contrary. We will see ALL UPnP devices. A white list enabled
without any entry is the same as no WL. This is for compatibility issue.
Calling this method followed by WhiteListAddInterface might
not be very efficient as it might result in us losing contexts and then
regaining them, i.e., DMSs might disappear and then re-appear.
More or less. If enabled = true at each call to WhiteListAddInterface,
potentially one or more servers could disappear.
if enabled = false, at each call to WhiteListAddInterface, nothing
happen. When changing enabled to true, you will receive all
notifications at this time.
Depending on the actions provided on the white list, we could not have
any overhead.
But if we move WL in dLeyna, all these API won't exist (except the one
discussed below)
So having said all this, my feeling is that something like
WhiteListSet(as interfaces) -> void
would be better than
> WhiteListAddInterface(s interface) -> b
> WhiteListRemoveInterface(s interface) -> b
> WhiteListResetInterface() -> void
Internally, dLeyna can translate WhiteListSet into the appropriate
whitelist_add and remove calls.
No more needed, as application doesn't have the right to manage the
whitelist directly. No need for API.
And for the dLeyna Settings App, GLib provide API for managing settings
file.
> WhiteListGetInterface() -> as
This should probably be WhiteListGetInterfaces, right? What does this
return? The list of interfaces in the whitelist or the list of current
active interfaces on the device. If it's the former, how does the
application work out work what values it can pass to
WhiteListAddInterface? Does it need to go to the network manager to
retrieve this information? Is there any way we could provide a
convenience method that would allow applications to easily retrieve this
information?
Bad naming => misunderstanding. Sorry for the confusion.
It should be WhiteListGetEntries and should return the list of entries
that compose the white list.
So, to resume, if we manage the WL in dLeyna, it simplifies a lot the API.
We don't need API to retrieve the white list. We can add it as a
property and use standard DBUS API for that.
We can let applications enable/disable WL. It could help them to scan a
network without modifying the WL.
Propositions & options:
Signal:
WhiteListChanged(asb)
Return the list of entries currently in the white list(as) and the state
of the WL (b), enabled or disabled.
This signal is raised each time the white list content or state is modified.
Properties:
WhiteListEnabled -> b
WhiteListEntries -> as (read only)
OPTIONS:
About WhiteListEnabled we can manage it in 2 ways:
1 - Specific API
WhiteListEnable(b enable) -> void
In this case, the property WhiteListEnabled is read only, and can be
retrieved with the DBUS properties API
2 - DBUS properties API
We don't add a specific API and use DBUS properties API to set and get
the values.
If we want a single WL for all dLeyna components, the safe way is to
manage another file. If we manage the setting entry in each already
existing settings file, we can have different valus (the file could be
edited manually, not only with an application). And we should take care
of this case.
If we want a WL for dleyna-server and one for dleyna-renderer, then we
can just add new entries in the current settings files.
My opinions is that we don't have the same needs for server & renderer.
In one case we get data, in the other, we send data. So I'm in favor of
separate WL for dleyna-server and dleyna-renderer.
About the properties, I'm in favor of using DBUS properties API, to
avoid to introduce mixed API, one for get, another one for set.
Ludo
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
3:54 p.m.
Hi Ludo,
One comment inline
On 07/03/2013 04:35 PM, Ludovic Ferrandis wrote:
Hi Mark,
On 03/07/2013 15:14, Mark Ryan wrote:
> Hi Ludo,
>
> In general it looks good to me. I have a few comments, inline
>
> On 06/27/2013 06:32 PM, Ludovic Ferrandis wrote:
>> Following email about context filtering in GUPnP, see message
>> <https://mail.gnome.org/archives/gupnp-list/2013-June/msg00011.html>
>>
>> What would be the impacts on dLeyna?
>> There will be more development for this component.
>> First, there will be a white list by servers using GUPnP, that means one
>> for dleyna-server and one for dleyna-renderer.
>> That implies all applications using the same dLeyna component (server or
>> renderer) will share the same white list.
>>
>> We need to provide APIs, so applications could manage their own white
>> list.
>> We need also to provide a signal, so applications using the same dLeyna
>> component, will be warned when another application is making change to
>> the white list.
>>
>>
>> How to manage the white list?
>>
>> dLeyna won't store any white list. It will just provide APIs, so
>> applications are going to be able to manage their own white list.
>> dLeyna won't provide a default white list, nor store a default white
>> list in its preferences.
>>
>
> Actually, I was thinking that the dLeyna components should store the
> whitelist. As there is only really one whitelist per dLeyna service it
> doesn't really make sense to require applications to manage these lists
> as they don't have much control over them. I think this will lead to
> confusion, e.g., the act of launching application A modifies the
> security settings of the already running application B.
>
There are pro & cons to each solution.
It depends where you want to manage this list of entries.
In your solution, the list should be managed (to be user friendly) by a
dleyna settings application, that doesn't exist for instance.
That means also, no API to modify the list of entries. Only dLeyna is
authorized to modify it.
It could be done this way. It simplifies applications, but add more
complexity to dLeyna.
> So, my feeling was the dLeyna services would store the whitelists and
> that the the APIs below would be used by a single settings application
> and not by individual dLeyna applications. This way there will be no
> confusion. The same settings application could provide the
> corresponding settings for the DMS and the DMR, so all your DLNA
> security settings would be localised in a single place.
>
>
As I explain in my first email, there are 2 solutions to store the
whitelist.
The first one, is to use the existing settings files, the second one is
to manage another settings file for whitelist.
In the first solution, the main advantage is that we already monitor the
settings file. We just need to add a new entry in the file.
The main inconvenience, is that potentially, we won't have the same
settings for the DMS & DMR.
Is it really a problem?
Another good point, the dLeyna Settings application will manage only 2
files.
The second solution is to manage another settings file only for the
whitelist.
We could have a common settings for server & renderer or a separate one.
The main inconvenience is that we should monitors 2 settings files. (But
we already have the code for that.)
>>
>> dLeyna dbus API:
>>
>> interface: com.intel.dLeynaServer.Manager
>>
>> Methods:
>>
>> WhiteListEnable(b enable) -> void
>> WhiteListAddInterface(s interface) -> b
>> WhiteListRemoveInterface(s interface) -> b
>> WhiteListGetInterface() -> as
>> WhiteListResetInterface() -> void
>>
>
At this point, I should mention that API should be renamed to follow
GUPnP naming, and replace 'interface' by 'entry'.
It's more accurate, as 'entry' could be an interface (eth,..), a SSID,
an IP address, etc...
And it's less confusing.
> From the point of view of a settings dialog, it's probably easier if
> there is a method that allows the whitelist to be replaced in one go,
> e.g., WhiteListSet(as interfaces).
2 points:
- There won't be dLeyna interface to modify the whitelist. It's an entry
in a settings file. To update the settings, the application will use
GLib API.
You mean by writing to the settings files directly? In general, I don't
think this will work. Applications may (should) not have the rights to
access this file and even if they did we probably wouldn't want them to
do this. What happens if two or more applications try to write to the
dLeyna settings file at the same time? Also, the settings file format
would essentially become part of our API, which would mean that we
couldn't change it without breaking applications. It's safer and
easier for everyone if we provide APIs to modify the settings.
- If we manage the WL in dLeyna, there won't be any public API
(except
the one discussed below), as dLeyna will call GUPnP API, but application
have nothing to do.
> Also, what happens if WhiteListEnable(True) has been called and then we
> call this WhiteListResetInterface? Does it mean we can't see any UPnP
> devices?
It's the contrary. We will see ALL UPnP devices. A white list enabled
without any entry is the same as no WL. This is for compatibility issue.
> Calling this method followed by WhiteListAddInterface might
> not be very efficient as it might result in us losing contexts and then
> regaining them, i.e., DMSs might disappear and then re-appear.
More or less. If enabled = true at each call to WhiteListAddInterface,
potentially one or more servers could disappear.
if enabled = false, at each call to WhiteListAddInterface, nothing
happen. When changing enabled to true, you will receive all
notifications at this time.
Depending on the actions provided on the white list, we could not have
any overhead.
But if we move WL in dLeyna, all these API won't exist (except the one
discussed below)
> So having said all this, my feeling is that something like
>
> WhiteListSet(as interfaces) -> void
>
> would be better than
>
>> WhiteListAddInterface(s interface) -> b
>> WhiteListRemoveInterface(s interface) -> b
>> WhiteListResetInterface() -> void
>
> Internally, dLeyna can translate WhiteListSet into the appropriate
> whitelist_add and remove calls.
>
>
No more needed, as application doesn't have the right to manage the
whitelist directly. No need for API.
And for the dLeyna Settings App, GLib provide API for managing settings
file.
>> WhiteListGetInterface() -> as
>
>
> This should probably be WhiteListGetInterfaces, right? What does this
> return? The list of interfaces in the whitelist or the list of current
> active interfaces on the device. If it's the former, how does the
> application work out work what values it can pass to
> WhiteListAddInterface? Does it need to go to the network manager to
> retrieve this information? Is there any way we could provide a
> convenience method that would allow applications to easily retrieve this
> information?
>
Bad naming => misunderstanding. Sorry for the confusion.
It should be WhiteListGetEntries and should return the list of entries
that compose the white list.
So, to resume, if we manage the WL in dLeyna, it simplifies a lot the API.
We don't need API to retrieve the white list. We can add it as a
property and use standard DBUS API for that.
We can let applications enable/disable WL. It could help them to scan a
network without modifying the WL.
Propositions & options:
Signal:
WhiteListChanged(asb)
Return the list of entries currently in the white list(as) and the state
of the WL (b), enabled or disabled.
This signal is raised each time the white list content or state is
modified.
Properties:
WhiteListEnabled -> b
WhiteListEntries -> as (read only)
OPTIONS:
About WhiteListEnabled we can manage it in 2 ways:
1 - Specific API
WhiteListEnable(b enable) -> void
In this case, the property WhiteListEnabled is read only, and can be
retrieved with the DBUS properties API
2 - DBUS properties API
We don't add a specific API and use DBUS properties API to set and get
the values.
If we want a single WL for all dLeyna components, the safe way is to
manage another file. If we manage the setting entry in each already
existing settings file, we can have different valus (the file could be
edited manually, not only with an application). And we should take care
of this case.
If we want a WL for dleyna-server and one for dleyna-renderer, then we
can just add new entries in the current settings files.
My opinions is that we don't have the same needs for server & renderer.
In one case we get data, in the other, we send data. So I'm in favor of
separate WL for dleyna-server and dleyna-renderer.
About the properties, I'm in favor of using DBUS properties API, to
avoid to introduce mixed API, one for get, another one for set.
Ludo
4:25 p.m.
On 03/07/2013 16:54, Mark Ryan wrote:
Hi Ludo,
One comment inline
On 07/03/2013 04:35 PM, Ludovic Ferrandis wrote:
> Hi Mark,
>
> On 03/07/2013 15:14, Mark Ryan wrote:
>> Hi Ludo,
>>
>> In general it looks good to me. I have a few comments, inline
>>
>> On 06/27/2013 06:32 PM, Ludovic Ferrandis wrote:
>>> Following email about context filtering in GUPnP, see message
>>> <https://mail.gnome.org/archives/gupnp-list/2013-June/msg00011.html>
>>>
>>> What would be the impacts on dLeyna?
>>> There will be more development for this component.
>>> First, there will be a white list by servers using GUPnP, that means
>>> one
>>> for dleyna-server and one for dleyna-renderer.
>>> That implies all applications using the same dLeyna component
>>> (server or
>>> renderer) will share the same white list.
>>>
>>> We need to provide APIs, so applications could manage their own white
>>> list.
>>> We need also to provide a signal, so applications using the same dLeyna
>>> component, will be warned when another application is making change to
>>> the white list.
>>>
>>>
>>> How to manage the white list?
>>>
>>> dLeyna won't store any white list. It will just provide APIs, so
>>> applications are going to be able to manage their own white list.
>>> dLeyna won't provide a default white list, nor store a default white
>>> list in its preferences.
>>>
>>
>> Actually, I was thinking that the dLeyna components should store the
>> whitelist. As there is only really one whitelist per dLeyna service it
>> doesn't really make sense to require applications to manage these lists
>> as they don't have much control over them. I think this will lead to
>> confusion, e.g., the act of launching application A modifies the
>> security settings of the already running application B.
>>
> There are pro & cons to each solution.
> It depends where you want to manage this list of entries.
> In your solution, the list should be managed (to be user friendly) by a
> dleyna settings application, that doesn't exist for instance.
> That means also, no API to modify the list of entries. Only dLeyna is
> authorized to modify it.
>
> It could be done this way. It simplifies applications, but add more
> complexity to dLeyna.
>
>> So, my feeling was the dLeyna services would store the whitelists and
>> that the the APIs below would be used by a single settings application
>> and not by individual dLeyna applications. This way there will be no
>> confusion. The same settings application could provide the
>> corresponding settings for the DMS and the DMR, so all your DLNA
>> security settings would be localised in a single place.
>>
>>
> As I explain in my first email, there are 2 solutions to store the
> whitelist.
> The first one, is to use the existing settings files, the second one is
> to manage another settings file for whitelist.
>
> In the first solution, the main advantage is that we already monitor the
> settings file. We just need to add a new entry in the file.
> The main inconvenience, is that potentially, we won't have the same
> settings for the DMS & DMR.
> Is it really a problem?
> Another good point, the dLeyna Settings application will manage only 2
> files.
>
> The second solution is to manage another settings file only for the
> whitelist.
> We could have a common settings for server & renderer or a separate one.
> The main inconvenience is that we should monitors 2 settings files. (But
> we already have the code for that.)
>
>>>
>>> dLeyna dbus API:
>>>
>>> interface: com.intel.dLeynaServer.Manager
>>>
>>> Methods:
>>>
>>> WhiteListEnable(b enable) -> void
>>> WhiteListAddInterface(s interface) -> b
>>> WhiteListRemoveInterface(s interface) -> b
>>> WhiteListGetInterface() -> as
>>> WhiteListResetInterface() -> void
>>>
>>
>
> At this point, I should mention that API should be renamed to follow
> GUPnP naming, and replace 'interface' by 'entry'.
> It's more accurate, as 'entry' could be an interface (eth,..), a SSID,
> an IP address, etc...
>
> And it's less confusing.
>
>
>> From the point of view of a settings dialog, it's probably easier if
>> there is a method that allows the whitelist to be replaced in one go,
>> e.g., WhiteListSet(as interfaces).
>
> 2 points:
> - There won't be dLeyna interface to modify the whitelist. It's an entry
> in a settings file. To update the settings, the application will use
> GLib API.
You mean by writing to the settings files directly? In general, I don't
think this will work. Applications may (should) not have the rights to
access this file and even if they did we probably wouldn't want them to
do this. What happens if two or more applications try to write to the
dLeyna settings file at the same time? Also, the settings file format
would essentially become part of our API, which would mean that we
couldn't change it without breaking applications. It's safer and
easier for everyone if we provide APIs to modify the settings.
> - If we manage the WL in dLeyna, there won't be any public API (except
> the one discussed below), as dLeyna will call GUPnP API, but application
> have nothing to do.
>
>> Also, what happens if WhiteListEnable(True) has been called and then we
>> call this WhiteListResetInterface? Does it mean we can't see any UPnP
>> devices?
> It's the contrary. We will see ALL UPnP devices. A white list enabled
> without any entry is the same as no WL. This is for compatibility issue.
>
>> Calling this method followed by WhiteListAddInterface might
>> not be very efficient as it might result in us losing contexts and then
>> regaining them, i.e., DMSs might disappear and then re-appear.
>
> More or less. If enabled = true at each call to WhiteListAddInterface,
> potentially one or more servers could disappear.
> if enabled = false, at each call to WhiteListAddInterface, nothing
> happen. When changing enabled to true, you will receive all
> notifications at this time.
> Depending on the actions provided on the white list, we could not have
> any overhead.
>
> But if we move WL in dLeyna, all these API won't exist (except the one
> discussed below)
>
>> So having said all this, my feeling is that something like
>>
>> WhiteListSet(as interfaces) -> void
>>
>> would be better than
>>
>>> WhiteListAddInterface(s interface) -> b
>>> WhiteListRemoveInterface(s interface) -> b
>>> WhiteListResetInterface() -> void
>>
>> Internally, dLeyna can translate WhiteListSet into the appropriate
>> whitelist_add and remove calls.
>>
>>
>
> No more needed, as application doesn't have the right to manage the
> whitelist directly. No need for API.
> And for the dLeyna Settings App, GLib provide API for managing settings
> file.
>
>>> WhiteListGetInterface() -> as
>>
>>
>> This should probably be WhiteListGetInterfaces, right? What does this
>> return? The list of interfaces in the whitelist or the list of current
>> active interfaces on the device. If it's the former, how does the
>> application work out work what values it can pass to
>> WhiteListAddInterface? Does it need to go to the network manager to
>> retrieve this information? Is there any way we could provide a
>> convenience method that would allow applications to easily retrieve this
>> information?
>>
>
> Bad naming => misunderstanding. Sorry for the confusion.
> It should be WhiteListGetEntries and should return the list of entries
> that compose the white list.
>
>
> So, to resume, if we manage the WL in dLeyna, it simplifies a lot the
> API.
>
> We don't need API to retrieve the white list. We can add it as a
> property and use standard DBUS API for that.
> We can let applications enable/disable WL. It could help them to scan a
> network without modifying the WL.
>
> Propositions & options:
>
> Signal:
>
> WhiteListChanged(asb)
> Return the list of entries currently in the white list(as) and the state
> of the WL (b), enabled or disabled.
> This signal is raised each time the white list content or state is
> modified.
>
> Properties:
>
> WhiteListEnabled -> b
> WhiteListEntries -> as (read only)
>
> OPTIONS:
> About WhiteListEnabled we can manage it in 2 ways:
>
> 1 - Specific API
> WhiteListEnable(b enable) -> void
> In this case, the property WhiteListEnabled is read only, and can be
> retrieved with the DBUS properties API
>
> 2 - DBUS properties API
> We don't add a specific API and use DBUS properties API to set and get
> the values.
>
>
> If we want a single WL for all dLeyna components, the safe way is to
> manage another file. If we manage the setting entry in each already
> existing settings file, we can have different valus (the file could be
> edited manually, not only with an application). And we should take care
> of this case.
>
> If we want a WL for dleyna-server and one for dleyna-renderer, then we
> can just add new entries in the current settings files.
>
> My opinions is that we don't have the same needs for server & renderer.
> In one case we get data, in the other, we send data. So I'm in favor of
> separate WL for dleyna-server and dleyna-renderer.
> About the properties, I'm in favor of using DBUS properties API, to
> avoid to introduce mixed API, one for get, another one for set.
>
> Ludo
>
>
No, what I mean exactly is:
1 - Applications could not update the while list. No API in dLeyna for this.
Otherwise we fallback to my first proposition and with the objections
you already provide (conflict, etc...)
But applications, if they really want, should be able to update
themselves the settings file, as there is no specific right on it.
dLeyna works on a copy installed in ~/.config/. Maybe we should set some
privilege to this file?
But I don't think external application will ever manage dLeyna settings.
2 - We need to provide an application that manage dLeyna settings.
The current one is very succinct (gedit), if not minimalist (vi) ;)
If dLeyna manages the settings, only dLeyna components should modify it.
3 - The only public action an application could apply on the WL is to
enable or disable it.
If a user want to change the content of the WL, he should do it using
the dleyna setting app (= gedit for instance)
Maybe we should provide a python app to manage dLeyna settings.
If we provide API to manage the WL, we are going to be in mixed solution
with applications that don't store the settings, but could change the
content of the WL already set by another application. Moreover, we are
going to provide API to manage only part of the settings...
Ludo
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
6:40 p.m.
Hi Ludo,
Sorry for the top posting.
The way we currently run things on Ubuntu, where we run on the session bus as the user, is
probably not going to be the norm. If we allow dLeyna to run on the system bus for
example, then the dLeyna services and the settings application will probably run as
different users. The settings application wouldn't then be able to modify the
settings file.
In addition, in dLeyna we generally provide APIs rather than applications. Providing APIs
for modifying the whitelist will allow people to write their own settings applications, on
any platform or dLeyna configuration.
Regards,
Mark
________________________________________
From: dleyna-bounces(a)lists.01.org [dleyna-bounces(a)lists.01.org] on behalf of Ludovic
Ferrandis [ludovic.ferrandis(a)intel.com]
Sent: Wednesday, July 03, 2013 5:25 PM
To: Mark Ryan
Cc: dleyna(a)lists.01.org
Subject: Re: [dLeyna] Security: Context filtering in dLeyna
On 03/07/2013 16:54, Mark Ryan wrote:
Hi Ludo,
One comment inline
On 07/03/2013 04:35 PM, Ludovic Ferrandis wrote:
> Hi Mark,
>
> On 03/07/2013 15:14, Mark Ryan wrote:
>> Hi Ludo,
>>
>> In general it looks good to me. I have a few comments, inline
>>
>> On 06/27/2013 06:32 PM, Ludovic Ferrandis wrote:
>>> Following email about context filtering in GUPnP, see message
>>> <https://mail.gnome.org/archives/gupnp-list/2013-June/msg00011.html>
>>>
>>> What would be the impacts on dLeyna?
>>> There will be more development for this component.
>>> First, there will be a white list by servers using GUPnP, that means
>>> one
>>> for dleyna-server and one for dleyna-renderer.
>>> That implies all applications using the same dLeyna component
>>> (server or
>>> renderer) will share the same white list.
>>>
>>> We need to provide APIs, so applications could manage their own white
>>> list.
>>> We need also to provide a signal, so applications using the same dLeyna
>>> component, will be warned when another application is making change to
>>> the white list.
>>>
>>>
>>> How to manage the white list?
>>>
>>> dLeyna won't store any white list. It will just provide APIs, so
>>> applications are going to be able to manage their own white list.
>>> dLeyna won't provide a default white list, nor store a default white
>>> list in its preferences.
>>>
>>
>> Actually, I was thinking that the dLeyna components should store the
>> whitelist. As there is only really one whitelist per dLeyna service it
>> doesn't really make sense to require applications to manage these lists
>> as they don't have much control over them. I think this will lead to
>> confusion, e.g., the act of launching application A modifies the
>> security settings of the already running application B.
>>
> There are pro & cons to each solution.
> It depends where you want to manage this list of entries.
> In your solution, the list should be managed (to be user friendly) by a
> dleyna settings application, that doesn't exist for instance.
> That means also, no API to modify the list of entries. Only dLeyna is
> authorized to modify it.
>
> It could be done this way. It simplifies applications, but add more
> complexity to dLeyna.
>
>> So, my feeling was the dLeyna services would store the whitelists and
>> that the the APIs below would be used by a single settings application
>> and not by individual dLeyna applications. This way there will be no
>> confusion. The same settings application could provide the
>> corresponding settings for the DMS and the DMR, so all your DLNA
>> security settings would be localised in a single place.
>>
>>
> As I explain in my first email, there are 2 solutions to store the
> whitelist.
> The first one, is to use the existing settings files, the second one is
> to manage another settings file for whitelist.
>
> In the first solution, the main advantage is that we already monitor the
> settings file. We just need to add a new entry in the file.
> The main inconvenience, is that potentially, we won't have the same
> settings for the DMS & DMR.
> Is it really a problem?
> Another good point, the dLeyna Settings application will manage only 2
> files.
>
> The second solution is to manage another settings file only for the
> whitelist.
> We could have a common settings for server & renderer or a separate one.
> The main inconvenience is that we should monitors 2 settings files. (But
> we already have the code for that.)
>
>>>
>>> dLeyna dbus API:
>>>
>>> interface: com.intel.dLeynaServer.Manager
>>>
>>> Methods:
>>>
>>> WhiteListEnable(b enable) -> void
>>> WhiteListAddInterface(s interface) -> b
>>> WhiteListRemoveInterface(s interface) -> b
>>> WhiteListGetInterface() -> as
>>> WhiteListResetInterface() -> void
>>>
>>
>
> At this point, I should mention that API should be renamed to follow
> GUPnP naming, and replace 'interface' by 'entry'.
> It's more accurate, as 'entry' could be an interface (eth,..), a SSID,
> an IP address, etc...
>
> And it's less confusing.
>
>
>> From the point of view of a settings dialog, it's probably easier if
>> there is a method that allows the whitelist to be replaced in one go,
>> e.g., WhiteListSet(as interfaces).
>
> 2 points:
> - There won't be dLeyna interface to modify the whitelist. It's an entry
> in a settings file. To update the settings, the application will use
> GLib API.
You mean by writing to the settings files directly? In general, I don't
think this will work. Applications may (should) not have the rights to
access this file and even if they did we probably wouldn't want them to
do this. What happens if two or more applications try to write to the
dLeyna settings file at the same time? Also, the settings file format
would essentially become part of our API, which would mean that we
couldn't change it without breaking applications. It's safer and
easier for everyone if we provide APIs to modify the settings.
> - If we manage the WL in dLeyna, there won't be any public API (except
> the one discussed below), as dLeyna will call GUPnP API, but application
> have nothing to do.
>
>> Also, what happens if WhiteListEnable(True) has been called and then we
>> call this WhiteListResetInterface? Does it mean we can't see any UPnP
>> devices?
> It's the contrary. We will see ALL UPnP devices. A white list enabled
> without any entry is the same as no WL. This is for compatibility issue.
>
>> Calling this method followed by WhiteListAddInterface might
>> not be very efficient as it might result in us losing contexts and then
>> regaining them, i.e., DMSs might disappear and then re-appear.
>
> More or less. If enabled = true at each call to WhiteListAddInterface,
> potentially one or more servers could disappear.
> if enabled = false, at each call to WhiteListAddInterface, nothing
> happen. When changing enabled to true, you will receive all
> notifications at this time.
> Depending on the actions provided on the white list, we could not have
> any overhead.
>
> But if we move WL in dLeyna, all these API won't exist (except the one
> discussed below)
>
>> So having said all this, my feeling is that something like
>>
>> WhiteListSet(as interfaces) -> void
>>
>> would be better than
>>
>>> WhiteListAddInterface(s interface) -> b
>>> WhiteListRemoveInterface(s interface) -> b
>>> WhiteListResetInterface() -> void
>>
>> Internally, dLeyna can translate WhiteListSet into the appropriate
>> whitelist_add and remove calls.
>>
>>
>
> No more needed, as application doesn't have the right to manage the
> whitelist directly. No need for API.
> And for the dLeyna Settings App, GLib provide API for managing settings
> file.
>
>>> WhiteListGetInterface() -> as
>>
>>
>> This should probably be WhiteListGetInterfaces, right? What does this
>> return? The list of interfaces in the whitelist or the list of current
>> active interfaces on the device. If it's the former, how does the
>> application work out work what values it can pass to
>> WhiteListAddInterface? Does it need to go to the network manager to
>> retrieve this information? Is there any way we could provide a
>> convenience method that would allow applications to easily retrieve this
>> information?
>>
>
> Bad naming => misunderstanding. Sorry for the confusion.
> It should be WhiteListGetEntries and should return the list of entries
> that compose the white list.
>
>
> So, to resume, if we manage the WL in dLeyna, it simplifies a lot the
> API.
>
> We don't need API to retrieve the white list. We can add it as a
> property and use standard DBUS API for that.
> We can let applications enable/disable WL. It could help them to scan a
> network without modifying the WL.
>
> Propositions & options:
>
> Signal:
>
> WhiteListChanged(asb)
> Return the list of entries currently in the white list(as) and the state
> of the WL (b), enabled or disabled.
> This signal is raised each time the white list content or state is
> modified.
>
> Properties:
>
> WhiteListEnabled -> b
> WhiteListEntries -> as (read only)
>
> OPTIONS:
> About WhiteListEnabled we can manage it in 2 ways:
>
> 1 - Specific API
> WhiteListEnable(b enable) -> void
> In this case, the property WhiteListEnabled is read only, and can be
> retrieved with the DBUS properties API
>
> 2 - DBUS properties API
> We don't add a specific API and use DBUS properties API to set and get
> the values.
>
>
> If we want a single WL for all dLeyna components, the safe way is to
> manage another file. If we manage the setting entry in each already
> existing settings file, we can have different valus (the file could be
> edited manually, not only with an application). And we should take care
> of this case.
>
> If we want a WL for dleyna-server and one for dleyna-renderer, then we
> can just add new entries in the current settings files.
>
> My opinions is that we don't have the same needs for server & renderer.
> In one case we get data, in the other, we send data. So I'm in favor of
> separate WL for dleyna-server and dleyna-renderer.
> About the properties, I'm in favor of using DBUS properties API, to
> avoid to introduce mixed API, one for get, another one for set.
>
> Ludo
>
>
No, what I mean exactly is:
1 - Applications could not update the while list. No API in dLeyna for this.
Otherwise we fallback to my first proposition and with the objections
you already provide (conflict, etc...)
But applications, if they really want, should be able to update
themselves the settings file, as there is no specific right on it.
dLeyna works on a copy installed in ~/.config/. Maybe we should set some
privilege to this file?
But I don't think external application will ever manage dLeyna settings.
2 - We need to provide an application that manage dLeyna settings.
The current one is very succinct (gedit), if not minimalist (vi) ;)
If dLeyna manages the settings, only dLeyna components should modify it.
3 - The only public action an application could apply on the WL is to
enable or disable it.
If a user want to change the content of the WL, he should do it using
the dleyna setting app (= gedit for instance)
Maybe we should provide a python app to manage dLeyna settings.
If we provide API to manage the WL, we are going to be in mixed solution
with applications that don't store the settings, but could change the
content of the WL already set by another application. Moreover, we are
going to provide API to manage only part of the settings...
Ludo
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
9:56 a.m.
Hi Mark,
I think mixed solution have more inconveniences.
If we let applications manage the WL settings of dLeyna that means each
application should provide its own UI to manage the WL.
But that doesn't prevent each application to have their own WL (in their
own settings) and to simply overwrite the current one in dLeyna calling
WLSetEntries().
In this case, we are in the same situation of my first proposition, plus
the complexity of managing the White List file in dLeyna.
I think we should do simple:
1 - dLeyna manage the WL file, but application doesn't have the right to
change it.
Then we should provide a system panel or application as example,
that will have the rights to change the WL files and ALL other dLeyna
settings.
This MAY lead to that the system displays the dialog to enter the
admin password.
Applications won't provide any UI to change the WL (at least, an UI
to show the active list)
In this case, it's not the applications that change the WL, but the
user (or system).
2 - dLeyna doesn't manage WL file. Application do and then should
provide an UI to change it.
dLeyna will just provide an API to return the current active WL and
to send the WL to GUPnP.
Application COULD take into account the current active WL before
updating it.
UI belongs of the applications and the WL is manage as other
settings of the applications
In this case, the WL is managed by the applications and not the
user (or system).
If we don't want that interactions occur between applications, we should
take option 1.
If we want to delegate more to applications and ado a minimal jobs in
dLeyna, then we should take option 2, but with the risk of interactions
between applications.
If we mix the solutions, we will always found edge cases.
As you point out in your first email, interactions between application
should be problematic. We can't rely on applications to respect some
guidelines on how to manage dLeyna WL.
So I tend to choose the first option.
Ludo
On 03/07/2013 19:40, Ryan, Mark D wrote:
Hi Ludo,
Sorry for the top posting.
The way we currently run things on Ubuntu, where we run on the session bus as the user,
is probably not going to be the norm. If we allow dLeyna to run on the system bus for
example, then the dLeyna services and the settings application will probably run as
different users. The settings application wouldn't then be able to modify the
settings file.
In addition, in dLeyna we generally provide APIs rather than applications. Providing
APIs for modifying the whitelist will allow people to write their own settings
applications, on any platform or dLeyna configuration.
Regards,
Mark
________________________________________
From: dleyna-bounces(a)lists.01.org [dleyna-bounces(a)lists.01.org] on behalf of Ludovic
Ferrandis [ludovic.ferrandis(a)intel.com]
Sent: Wednesday, July 03, 2013 5:25 PM
To: Mark Ryan
Cc: dleyna(a)lists.01.org
Subject: Re: [dLeyna] Security: Context filtering in dLeyna
On 03/07/2013 16:54, Mark Ryan wrote:
> Hi Ludo,
>
> One comment inline
>
>
> On 07/03/2013 04:35 PM, Ludovic Ferrandis wrote:
>> Hi Mark,
>>
>> On 03/07/2013 15:14, Mark Ryan wrote:
>>> Hi Ludo,
>>>
>>> In general it looks good to me. I have a few comments, inline
>>>
>>> On 06/27/2013 06:32 PM, Ludovic Ferrandis wrote:
>>>> Following email about context filtering in GUPnP, see message
>>>>
<https://mail.gnome.org/archives/gupnp-list/2013-June/msg00011.html>
>>>>
>>>> What would be the impacts on dLeyna?
>>>> There will be more development for this component.
>>>> First, there will be a white list by servers using GUPnP, that means
>>>> one
>>>> for dleyna-server and one for dleyna-renderer.
>>>> That implies all applications using the same dLeyna component
>>>> (server or
>>>> renderer) will share the same white list.
>>>>
>>>> We need to provide APIs, so applications could manage their own white
>>>> list.
>>>> We need also to provide a signal, so applications using the same dLeyna
>>>> component, will be warned when another application is making change to
>>>> the white list.
>>>>
>>>>
>>>> How to manage the white list?
>>>>
>>>> dLeyna won't store any white list. It will just provide APIs, so
>>>> applications are going to be able to manage their own white list.
>>>> dLeyna won't provide a default white list, nor store a default white
>>>> list in its preferences.
>>>>
>>> Actually, I was thinking that the dLeyna components should store the
>>> whitelist. As there is only really one whitelist per dLeyna service it
>>> doesn't really make sense to require applications to manage these lists
>>> as they don't have much control over them. I think this will lead to
>>> confusion, e.g., the act of launching application A modifies the
>>> security settings of the already running application B.
>>>
>> There are pro & cons to each solution.
>> It depends where you want to manage this list of entries.
>> In your solution, the list should be managed (to be user friendly) by a
>> dleyna settings application, that doesn't exist for instance.
>> That means also, no API to modify the list of entries. Only dLeyna is
>> authorized to modify it.
>>
>> It could be done this way. It simplifies applications, but add more
>> complexity to dLeyna.
>>
>>> So, my feeling was the dLeyna services would store the whitelists and
>>> that the the APIs below would be used by a single settings application
>>> and not by individual dLeyna applications. This way there will be no
>>> confusion. The same settings application could provide the
>>> corresponding settings for the DMS and the DMR, so all your DLNA
>>> security settings would be localised in a single place.
>>>
>>>
>> As I explain in my first email, there are 2 solutions to store the
>> whitelist.
>> The first one, is to use the existing settings files, the second one is
>> to manage another settings file for whitelist.
>>
>> In the first solution, the main advantage is that we already monitor the
>> settings file. We just need to add a new entry in the file.
>> The main inconvenience, is that potentially, we won't have the same
>> settings for the DMS & DMR.
>> Is it really a problem?
>> Another good point, the dLeyna Settings application will manage only 2
>> files.
>>
>> The second solution is to manage another settings file only for the
>> whitelist.
>> We could have a common settings for server & renderer or a separate one.
>> The main inconvenience is that we should monitors 2 settings files. (But
>> we already have the code for that.)
>>
>>>> dLeyna dbus API:
>>>>
>>>> interface: com.intel.dLeynaServer.Manager
>>>>
>>>> Methods:
>>>>
>>>> WhiteListEnable(b enable) -> void
>>>> WhiteListAddInterface(s interface) -> b
>>>> WhiteListRemoveInterface(s interface) -> b
>>>> WhiteListGetInterface() -> as
>>>> WhiteListResetInterface() -> void
>>>>
>> At this point, I should mention that API should be renamed to follow
>> GUPnP naming, and replace 'interface' by 'entry'.
>> It's more accurate, as 'entry' could be an interface (eth,..), a
SSID,
>> an IP address, etc...
>>
>> And it's less confusing.
>>
>>
>>> From the point of view of a settings dialog, it's probably easier if
>>> there is a method that allows the whitelist to be replaced in one go,
>>> e.g., WhiteListSet(as interfaces).
>> 2 points:
>> - There won't be dLeyna interface to modify the whitelist. It's an entry
>> in a settings file. To update the settings, the application will use
>> GLib API.
> You mean by writing to the settings files directly? In general, I don't
> think this will work. Applications may (should) not have the rights to
> access this file and even if they did we probably wouldn't want them to
> do this. What happens if two or more applications try to write to the
> dLeyna settings file at the same time? Also, the settings file format
> would essentially become part of our API, which would mean that we
> couldn't change it without breaking applications. It's safer and
> easier for everyone if we provide APIs to modify the settings.
>
>
>> - If we manage the WL in dLeyna, there won't be any public API (except
>> the one discussed below), as dLeyna will call GUPnP API, but application
>> have nothing to do.
>>
>>> Also, what happens if WhiteListEnable(True) has been called and then we
>>> call this WhiteListResetInterface? Does it mean we can't see any UPnP
>>> devices?
>> It's the contrary. We will see ALL UPnP devices. A white list enabled
>> without any entry is the same as no WL. This is for compatibility issue.
>>
>>> Calling this method followed by WhiteListAddInterface might
>>> not be very efficient as it might result in us losing contexts and then
>>> regaining them, i.e., DMSs might disappear and then re-appear.
>> More or less. If enabled = true at each call to WhiteListAddInterface,
>> potentially one or more servers could disappear.
>> if enabled = false, at each call to WhiteListAddInterface, nothing
>> happen. When changing enabled to true, you will receive all
>> notifications at this time.
>> Depending on the actions provided on the white list, we could not have
>> any overhead.
>>
>> But if we move WL in dLeyna, all these API won't exist (except the one
>> discussed below)
>>
>>> So having said all this, my feeling is that something like
>>>
>>> WhiteListSet(as interfaces) -> void
>>>
>>> would be better than
>>>
>>>> WhiteListAddInterface(s interface) -> b
>>>> WhiteListRemoveInterface(s interface) -> b
>>>> WhiteListResetInterface() -> void
>>> Internally, dLeyna can translate WhiteListSet into the appropriate
>>> whitelist_add and remove calls.
>>>
>>>
>> No more needed, as application doesn't have the right to manage the
>> whitelist directly. No need for API.
>> And for the dLeyna Settings App, GLib provide API for managing settings
>> file.
>>
>>>> WhiteListGetInterface() -> as
>>>
>>> This should probably be WhiteListGetInterfaces, right? What does this
>>> return? The list of interfaces in the whitelist or the list of current
>>> active interfaces on the device. If it's the former, how does the
>>> application work out work what values it can pass to
>>> WhiteListAddInterface? Does it need to go to the network manager to
>>> retrieve this information? Is there any way we could provide a
>>> convenience method that would allow applications to easily retrieve this
>>> information?
>>>
>> Bad naming => misunderstanding. Sorry for the confusion.
>> It should be WhiteListGetEntries and should return the list of entries
>> that compose the white list.
>>
>>
>> So, to resume, if we manage the WL in dLeyna, it simplifies a lot the
>> API.
>>
>> We don't need API to retrieve the white list. We can add it as a
>> property and use standard DBUS API for that.
>> We can let applications enable/disable WL. It could help them to scan a
>> network without modifying the WL.
>>
>> Propositions & options:
>>
>> Signal:
>>
>> WhiteListChanged(asb)
>> Return the list of entries currently in the white list(as) and the state
>> of the WL (b), enabled or disabled.
>> This signal is raised each time the white list content or state is
>> modified.
>>
>> Properties:
>>
>> WhiteListEnabled -> b
>> WhiteListEntries -> as (read only)
>>
>> OPTIONS:
>> About WhiteListEnabled we can manage it in 2 ways:
>>
>> 1 - Specific API
>> WhiteListEnable(b enable) -> void
>> In this case, the property WhiteListEnabled is read only, and can be
>> retrieved with the DBUS properties API
>>
>> 2 - DBUS properties API
>> We don't add a specific API and use DBUS properties API to set and get
>> the values.
>>
>>
>> If we want a single WL for all dLeyna components, the safe way is to
>> manage another file. If we manage the setting entry in each already
>> existing settings file, we can have different valus (the file could be
>> edited manually, not only with an application). And we should take care
>> of this case.
>>
>> If we want a WL for dleyna-server and one for dleyna-renderer, then we
>> can just add new entries in the current settings files.
>>
>> My opinions is that we don't have the same needs for server & renderer.
>> In one case we get data, in the other, we send data. So I'm in favor of
>> separate WL for dleyna-server and dleyna-renderer.
>> About the properties, I'm in favor of using DBUS properties API, to
>> avoid to introduce mixed API, one for get, another one for set.
>>
>> Ludo
>>
>>
No, what I mean exactly is:
1 - Applications could not update the while list. No API in dLeyna for this.
Otherwise we fallback to my first proposition and with the objections
you already provide (conflict, etc...)
But applications, if they really want, should be able to update
themselves the settings file, as there is no specific right on it.
dLeyna works on a copy installed in ~/.config/. Maybe we should set some
privilege to this file?
But I don't think external application will ever manage dLeyna settings.
2 - We need to provide an application that manage dLeyna settings.
The current one is very succinct (gedit), if not minimalist (vi) ;)
If dLeyna manages the settings, only dLeyna components should modify it.
3 - The only public action an application could apply on the WL is to
enable or disable it.
If a user want to change the content of the WL, he should do it using
the dleyna setting app (= gedit for instance)
Maybe we should provide a python app to manage dLeyna settings.
If we provide API to manage the WL, we are going to be in mixed solution
with applications that don't store the settings, but could change the
content of the WL already set by another application. Moreover, we are
going to provide API to manage only part of the settings...
Ludo
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
11:53 a.m.
Hi Ludo,
On 07/04/2013 10:56 AM, Ludovic Ferrandis wrote:
Hi Mark,
I think mixed solution have more inconveniences.
If we let applications manage the WL settings of dLeyna that means each
application should provide its own UI to manage the WL.
But that doesn't prevent each application to have their own WL (in their
own settings) and to simply overwrite the current one in dLeyna calling
WLSetEntries().
In this case, we are in the same situation of my first proposition, plus
the complexity of managing the White List file in dLeyna.
I think we should do simple:
1 - dLeyna manage the WL file, but application doesn't have the right to
change it.
Then we should provide a system panel or application as example,
that will have the rights to change the WL files and ALL other dLeyna
settings.
This MAY lead to that the system displays the dialog to enter the
admin password.
Applications won't provide any UI to change the WL (at least, an UI
to show the active list)
In this case, it's not the applications that change the WL, but the
user (or system).
2 - dLeyna doesn't manage WL file. Application do and then should
provide an UI to change it.
dLeyna will just provide an API to return the current active WL and
to send the WL to GUPnP.
Application COULD take into account the current active WL before
updating it.
UI belongs of the applications and the WL is manage as other
settings of the applications
In this case, the WL is managed by the applications and not the
user (or system).
If we don't want that interactions occur between applications, we should
take option 1.
If we want to delegate more to applications and ado a minimal jobs in
dLeyna, then we should take option 2, but with the risk of interactions
between applications.
If we mix the solutions, we will always found edge cases.
As you point out in your first email, interactions between application
should be problematic. We can't rely on applications to respect some
guidelines on how to manage dLeyna WL.
So I tend to choose the first option.
Yes, I agree, option 1 is the way to go. We want to have dLeyna manage
the whitelists. What we seem to disagree on at the moment is how those
whitelists can be edited, but this should not prevent us from starting
work on whitelist support in dLeyna. In parallel, we can continue to
investigate the best solution for modifying the settings.
Best Regards,
Mark
2:18 p.m.
On 3 July 2013 20:40, Ryan, Mark D <mark.d.ryan(a)intel.com> wrote:
The way we currently run things on Ubuntu, where we run on the session bus
as the user, is probably not going to be the norm. If we allow dLeyna to
run on the system bus for example, then the dLeyna services and the
settings application will probably run as different users. The settings
application wouldn't then be able to modify the settings file.
In addition, in dLeyna we generally provide APIs rather than applications.
Providing APIs for modifying the whitelist will allow people to write
their own settings applications, on any platform or dLeyna configuration.
I haven't fully grasped the whole context filtering thing yet but on this
issue I strongly agree with Mark: files that are modifiable by multiple
apps are plain evil, whatever the situation. Things will break -- it's
easy to assume that "in practice these apps won't write at same time" and
later find out they actually both write settings based on the same external
signal, i.e. at the same time.
If we know that we work in a per-user GNOME environment, then GSettings
(dconf) is the obvious place to store settings in a safe way but that is
not suitable for other environments or system-wide setups.
Jussi
3:05 p.m.
On 05/07/2013 15:18, Jussi Kukkonen wrote:
On 3 July 2013 20:40, Ryan, Mark D <mark.d.ryan(a)intel.com
<mailto:mark.d.ryan@intel.com>> wrote:
The way we currently run things on Ubuntu, where we run on the
session bus as the user, is probably not going to be the norm. If
we allow dLeyna to run on the system bus for example, then the
dLeyna services and the settings application will probably run as
different users. The settings application wouldn't then be able
to modify the settings file.
In addition, in dLeyna we generally provide APIs rather than
applications. Providing APIs for modifying the whitelist will
allow people to write their own settings applications, on any
platform or dLeyna configuration.
I haven't fully grasped the whole context filtering thing yet but on
this issue I strongly agree with Mark: files that are modifiable by
multiple apps are plain evil, whatever the situation. Things will
break -- it's easy to assume that "in practice these apps won't write
at same time" and later find out they actually both write settings
based on the same external signal, i.e. at the same time.
Agree. This is one of the
reasons I don't want public API too to update
the settings, even if in this case, dLeyna will serialize the calls. The
last application that call the API win.
Based on your 'external signal', in the worst case with bad written
applications, you can even have an infinite loop. App1 & App2 when they
receive the signal that WL has changed, check the list, and if if
doesn't match the one they have, overwrite the new one with their own
WL. APP1 & APP2 change the list indefinitely.
I think we could not even imagine, how many bad cases with applications
that can modify the WL themselves, people can dream up :)
This is also why I prefer a single 'app/control apnel/other' that would
be the only app with rights to be able to update the settings. No access
to external applications. And depending of the platform integration, it
could be add in the system/app control panel.
But for instance, how to manage the settings with UI is a pending
question. We need to found a secure solution.
If we know that we work in a per-user GNOME environment, then
GSettings (dconf) is the obvious place to store settings in a safe way
but that is not suitable for other environments or system-wide setups.
Currently settings are manage using GKeyFile, that is part of GLib, so
multi-platform.
Ludo
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
3:17 p.m.
On 5 July 2013 14:18, Jussi Kukkonen <jussi.kukkonen(a)intel.com> wrote:
If we know that we work in a per-user GNOME environment, then
GSettings
(dconf) is the obvious place to store settings in a safe way but that is not
suitable for other environments or system-wide setups.
GSettings is multiplatform and there are multiple backends (memory,
keyfile, Win32 registry, dconf), so it is an obvious replacement for
GKeyFile.
Ross
3237
days inactive
3245
days old
10 comments
5 participants
participants (5)
-
Burton, Ross -
Jussi Kukkonen -
Ludovic Ferrandis -
Mark Ryan -
Ryan, Mark D