On Wed, May 7, 2014, at 3:58, Lorenzo Colitti wrote:

On Wed, May 7, 2014 at 6:24 PM, Hannes Frederic Sowa
[off-list ref] wrote:

quoted

I question the abstraction of using UIDs for matching routing rules.
E.g. freebsd uses setfib[1] to alter the view of the routing table per
process. E.g. an interface like ip rule exec (action ACTION)+ PROGRAM
would be much nicer in combination with a prctl, maybe? I would much
rather enjoy an interface not based on UIDs. Would something like that
solve your initial problem?

So you're suggesting something that would still be an ip rule, but
would match a new identifier ("fibgroup") rather than the uid? I think
that would work, though obviously it's a much bigger change than what
I am proposing here.

It would require defining a new identifier, figuring out what its
semantics are, setting it when socket objects are created, attaching
it to sockets across accept/fork, etc. Userspace code would have to be
update it to set it on processes (whereas the uid is already dealt
with by existing tools), etc.

That was my idea, yes. Having some kind of opaque identifier with
user-friendly names a la /etc/iproute2/rt_tables which can be used in ip
rule matches.

I see, it would require very heavy lifting, but in the end seems to be
more user-friendly to me than uids. But I guess task_struct is something
like sk_buff, where you need to find very good arguments to expand it.

Maybe something like cgroup/net_cls.classid would be possible, but I am
not familar on how to interact with cgroups internally and don't know
how much work that would be (and if more network cgroup interaction is
actually desirable).

If you're proposing something not that's not an ip rule, then that
seems like a step backwards, because it won't allow the rich policy
allowed by processing rules in priority order, throw routes, FRA_GOTO,
etc.

Agreed.

Bye,

  Hannes