> Just a heads up... I just committed a change to the routing socket code
> that allow non-superuser to open, listen, and perform RTM_GET.  This
> is sufficient to allow normal use of /sbin/route, and have permissions of
> all routing table changes enforced in the kernel.  /sbin/route is no
> longer setuid-root.

Thank you!  I have really hated dealing with route being setuid and
enforcing permissions based on real user id.  I'd like to propose some
further changes.

Can we now remove the call to getuid() in sbin/route/route.c ?  Either
that or change it to geteuid().  But since the kernel now enforces
modifications to the routing socket, I would prefer completely removing
this.

The functional change (and the reason I'm motivated to do this) is the
ability to have setuid shell scripts that call route(1).  Prior to these
changes, you could not have setuid shell scripts call route(1) with special
privileges because it was already setuid.  But now it would be nice to
enable that.  I claim there isn't any security compromise in this.  If
there is a security problem with setuid shell-scripts or programs, we have
much worse problems than route(1).  But since route is no longer setuid and
the kernel is enforcing privileges, it seems redundant (and is annoying) to
have route(1) do so as well.  Besides, any joe user can compile a version
of route without the uid checks.

The only difference to the user between removing the getuid() (and
associated checks) and changing it to geteuid() is that the user sees:
	writing to routing socket: Permission denied
instead of
	must be root to alter routing table
if their permissions are wrong.  I don't think the latter is that much more
helpful.  But to even things out, if I remove route(1)'s uid checks, I'll
add a blurb to the DIAGNOSTICS section of the man page for "Permission
Denied".

If I get no objections, I'll check this in.  My patch simply removes all
existance of the uid variable and associated checks and error messages.

Dave