On Thu, 2013-11-07 at 10:05 -0500, Glenn Schmottlach wrote:
> >> So it would appear the *last* session that is created will
> effectively
> >> mark (and clobber) the first marking for the packet (0x101 mark
> >> clobbers the earlier 0x100 mark since it's last in the chain). I
> hope
> >> this is *not* what was intended. I expected that iptable rules for
> >> Session policies for the same UID/GID/SELinux context would "share"
> >> the same session (and thus statistics). So if two applications
> running
> >> as the same UID/GID/SELinux context requested a Connman Session,
> the
> >> first requestor would create it while the second application would
> get
> >> a "reference" to that session. This session would remain valid
> until
> >> the last application (with the same UID/GID/SELinux context)
> destroyed
> >> the session. In a sense the Sessions become reference counted per
> >> session policy. As it stands today it would appear Connman creates
> far
> >> more iptable rules than necessary to support multiple applications
> >> running as the same user (or in the same group or SELinux context).
> Am
> >> I correct in assuming this is a design error in the current
> >> implementation of Sessions?
> >
> >
> > You are right. We need to fix this. Patches? :D
Both processes need to be notified separately as they have independently
asked that via D-Bus. The approach here is to keep two separate sessions
over D-Bus, one for each process, while setting up the netfilter rules
only once per matching policy.
Cheers,
Patrik
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
