Re: capable() during kernel init was Re: 2.1.111: Could not allocate TCP control block

Andi Kleen (ak@muc.de)
Thu, 30 Jul 1998 18:48:33 +0200

On Thu, Jul 30, 1998 at 06:39:00PM +0200, Andrew Morgan wrote:
>
> Andi,
>
> I think we are agreed on the following fact: the capable() code, by
> design, only makes sense for tasks. If the kernel is in a
> pre-task-available state, then the capable call should not be made.
>
> If it wasn't a bad idea, you could work around this problem with:
>
> case SOCK_RAW:
> if (!capable(CAP_NET_RAW))
> goto free_and_badperm;
> + case _SOCK_RAW_INIT:
> if (!protocol)
>
> But this obviously suffers from the fact that this "internal"
> sock->type is instantly available to user space.

This does not work, because the value is later used for other purposes
too. I fixed it now by moving sock_init() into the init task.

> Its not clear to me why the initialization needs to use the generic
> capability filtered code sequence at all. Logically, we are
> attempting to run before we can walk.

The kernel internally opens a socket to send ICMP and TCP RST packets,
and just uses the generic function to avoid duplicate code. The networking
code internally is strictly layered and some kind of object oriented
[uses vtables a lot], and it would be hard to change that.

> Since Linus wants things fast _and_ maintainable, I think I would
> investigate delaying the initialization of the ip code until after the
> current task has been properly initialized.

That's the current fix, yes.

Thanks,

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html