Re: kdbus: add driver skeleton, ioctl entry points and utility functions

[Eric W. Biederman]

Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes:

> From: Daniel Mack <daniel@xxxxxxxxxx>
>
> Add the basic driver structure.
>
> handle.c is the main ioctl command dispatcher that calls into other parts
> of the driver.
>
> main.c contains the code that creates the initial domain at startup, and
> util.c has utility functions such as item iterators that are shared with
> other files.
>
> limits.h describes limits on things like maximum data structure sizes,
> number of messages per users and suchlike. Some of the numbers currently
> picked are rough ideas of what what might be sufficient and are probably
> rather conservative.
>
> Signed-off-by: Daniel Mack <daniel@xxxxxxxxxx>
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>


> +/* kdbus control device commands */
> +static long kdbus_handle_ioctl_control(struct file *file, unsigned int cmd,
> +				       void __user *buf)
> +{
> +	case KDBUS_CMD_DOMAIN_MAKE: {
> +		const char *name;
> +
> +		if (!capable(CAP_IPC_OWNER)) {
> +			ret = -EPERM;
> +			break;
> +		}

I don't know if this is exploitable (given that this happens in an
ioctl) but capable checks outside of open usually are.

Eric


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/