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

- List: linux-api
- 1 message, 1 author
- Page: https://ratatoskr.run/linux-api/2014/10/4362721/t

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

- From: Eric W. Biederman \<hidden\>
- Date: 2014-10-30 03:52:07 
- Message: https://ratatoskr.run/linux-api/2014/10/4362721.md

```text
Greg Kroah-Hartman [ref] writes:

> From: Daniel Mack <redacted>
>
> 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 <redacted>
> Signed-off-by: Greg Kroah-Hartman <redacted>


> +/* 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
```