Re: GUPnP and Zones

[Ludovic Ferrandis <ludovic ferrandis linux intel com>]

On 25/04/2013 11:06, Jussi Kukkonen wrote:
> On 24 April 2013 18:54, Mark Ryan <mark d ryan linux intel com> wrote:
> > > For the first two cases adding another layer of UI (outside the apps
> > > control) seems wrong, and I wouldn't be surprised if app developers
> > > would be annoyed about that. I don't have specific ideas about how to
> > > solve this but I think the apps should have fairly strong control over
> > > this.
> >
> > I agree with this and this case is covered to some extent by the proposal in
> > my original email.  The idea would be to
> >
> > a) use zone information, where available, to provide a safe set of defaults
> > for UPnP clients and servers
> >
> > b) add a new API to GUPnP to allow clients ( UPnP control points and servers
> > ) to override these defaults.
> >
> > So ultimately, the applications would retain control.
>
> Oh, now I get it, you did cover that. I got confused by the later
> "could be overridden by a compile time option" but that was actually
> somewhat unrelated.
>
> > Of course, if we implemented this feature, we would change the default
> > behaviour (i.e. to share everything on all networks) of existing GUPnP
> > clients where zone information is available.  But giving the security risks
> > maybe this isn't such a bad thing.  If clients wanted to revert to the old
> > behaviour, they would need to update their code to use the new API.
>
> I don't think it would be bad if the default stayed as it is: apps
> would have to enable the whitelisting functionality explicitly instead
> of it being the default -- I think this is what most apps will want
> anyway.
> At the very least we should make sure this does break the API if we
> change the default: otherwise apps will just silently stop working
> when distros upgrade gupnp.
>
> > There is of course a caveat for dLeyna clients here.  Apps that used the
> > dLeyna components would share the same set of settings for accessing
> > networks.
>
> I assume you don't mean the gupnp whitelists would be per-application,
> but are talking about the case where one dleyna-app decides that it
> really wants to see all the mediaservers regardless of whitelists, and
> as a result all the dleyna-using apps end up seeing them? This sounds
> fine to me.
>
> - Jussi
> _______________________________________________
> gupnp-list mailing list
> gupnp-list gnome org
> https://mail.gnome.org/mailman/listinfo/gupnp-list

I must said I'm a little confused about your proposals and about the 
direction which takes this discussion.

As Mark said in the first email:
> The good news now is that it seems that Network Manager, in conjunction with firewalld, now support the 
> concept of zones. ( http://lwn.net/Articles/484506/ ).
> The question is, how can we take advantage of zone support in GUPnP/Rygel/dLeyna.

So, are we talking about managing 'white list', or real support of zones 
provided by the Network Manager?

If the goal is to support the Network Manager zones new feature, we 
should work with the Network Manager team to ensure DLNA rules are 
correctly managed in the various zones.

But we have nothing to do in GUPnP/Rygel/dLeyna as it's NM that will 
allow or deny networks.

If your proposal of 'white list' is in addition to Network Zone, then 
this is a lame solution, as your solution will only works on networks 
already granted by NM.

You won't be able to enable a network, even if you add it in the white 
list, if NM has already blocked it.
We will only be able to block a network previously granted by NM.

This is the worst case, as I think it will be complicated enough for 
users to apprehend the new zone concept (and modify firewall rules) 
without adding more complexities in GUPnP.
I let you try to explain to users that the network they add to the while 
list is still blocked :)

Moreover, the concept of white list is a good one for network managers 
without the support of zones. But this is not the initial subject of 
this thread.


--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation