On Tue, Sep 05, 2000 at 07:31:20PM +0200, A.N.Kuznetsov wrote:
> > Alexey can complain next week when he comes back online. :-)
> Nothing to complain. 8)
> BTW, Paul, we can make one interesting thing now.
> Namely, something sort of setsockopt(SO_NFMARK).
> After this you can override socket(2) (f.e. with LD_PRELOAD
> or on application level) and select nfmark depending
> on some environment variable.
I thought about something like this in the past to fix IPSec. IPSec
has to select special routes with smaller MTU to include its headers.
One idea was to use more TOS bits, the other to use a nfmark in the
socket. The problem with using the nfmark (or bits of the nfmark)
is that it can cause collisions with other nfmark users. Adding a IPsec
TOS bit may therefore be better.
> The only problem is how to prevent user to override
> internal nfmarks (nat). Well, and security implications are to be
> analyzed. Probably, it is enough to add sysctl variable sort of
> nfmark_user_mask (set to zero by default) and allow to change
> nfmark via setsockopt() only if (nfmark_user_mask&nfmark) == nfmark.
It would be nicer if that nfmark_user_mask was part of task_struct
and would be inherited through fork, but could be only changed by root
(or appropiate capability)
This way you could e.g. allow certain users only limited bandwidth via
a special PAM module or an extension to pam_limits.
This is like TV. I don't like TV.