Hi Patrik - See my comments below . . .
On Thu, Nov 7, 2013 at 3:05 AM, Patrik Flykt <patrik.fl...@linux.intel.com> wrote: > > Hi, > > On Tue, 2013-11-05 at 14:27 -0500, Glenn Schmottlach wrote: >> It seems that when a Session is created new >> rules are added to the iptable to "mark" these packets from a >> particular application based on the UID, GID, or SELinux context. > > Yes. > >> I want to set up additional filters on these same marked packets >> except I also want to add a field to mark a GID association in the >> same U32 netfilter value. > > Why do you want to want to reuse the marker value? > > What is your intention: do you need per UID stats, per GID stats (or per > SELinux context stats) or all of them at the same time? If you need > combined stats for some set of applications and another combined set of > stats for different (but possibly overlapping?) set of applications, is > it just easier to calculate that value based on the per UID stats (or > GID/SELinux) set up by ConnMan? With that any sets of group stats can be > created with any sets of overlaps. > Yes, I need to collectively collect both per UID (or application in my situation) statistics as well as group (GID) statistics which may include multiple UIDs. Besides collecting these statistics I must also *enforce* data quotas on a per UID *and* GID basis. This is certainly awkward and likely infeasible to do using the Connman statistics gathering API because it is necessarily coarse (with suggested granularity in the kilobyte range) and provides no mechanism to effectively shut-off data access for a particular UID or collection of UIDs (e.g. GID). The best place to do this is with a netfilter rule and I have prototyped such a solution by hand-crafting such rules. Unfortunately, the Connman of today appears to make the assumption that it has exclusive ownership (and marking rights) to packets that pass through iptables. In my use case I would like to make sure Connman only modifies a certain range of those bits and masks out my "additional" bits when it does its matching. If my statistics collection feature resides outside of Connman then I need to know the range of bits Connman is marking as well as the mask I need to apply to block those bits when I set up my own iptable matching rules. Plus, in some cases I may want to match on the same packets that Connman is using so I need to know the pattern to look for in my iptable rule. >> I need to know the netfilter mask I can use >> to mask off the fields Connman uses for each packet. > > This starts to get awfully complicated... > >> 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. > > Only one session needs and can be created. This is done by the "main" > process with the rest of the forked off childred being automatically > accounted for as long as they keep the same UID/GID/SELinux context used > for identification purposes. Only if they change the identification they > need to open a new Session in order to get routing, notifications and > accounting set up properly. > 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. 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. Thanks, Glenn > Cheers, > > Patrik > > _______________________________________________ > connman mailing list > connman@connman.net > https://lists.connman.net/mailman/listinfo/connman _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
