Hi,
On Thu, 2013-11-07 at 09:14 -0500, Glenn Schmottlach wrote:
> It seems you're trying to use a programming "convention" (a single
> main process that is responsible for session creation and forks
> children processes) as a means to prevent more than one session for
> the same UID/GID/SELinux context from being created.
No. I tried to say that a Session for ConnMan can consist of N
processes, where each process belongs to the set matched on UID, GID or
SELinux context. Routing (and accounting) is then shared for this set.
One or more of the N processes needs to request a Session for the all
this to be set up.
> All the
> network-aware processes for a given UID/GID/SELinux context may not be
> aware of one another and each could conceivably want to create a
> session. I would expect the session policy for a given UID/GID/SELinux
> context to apply to processes run under that policy. They should
> effective share the same Session policy no matter which process
> creates the Session first (e.g. a reference counted policy). As it
> stands today, if I run the Session test program twice (as the same
> user) I get two separate Sessions with duplicate iptable rules that
> clobber one another. I would think Connman should prevent this
> behavior.
This in the context of...
> 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.
...in the other thread means there is a bug. If the same policy matches
the other session, no duplicate netfilter rules must be inserted, and
especially not in a way where the previous marking is overwritten. But
do notice that ConnMan must set up two separate Sessions, one for each
process (as currently) as both processes have asked to be notified
(separately). It's the netfilter rules that need to be set up only once.
Bug, needs fixing.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
