lkml.org 
[lkml]   [2014]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: kdbus: add driver skeleton, ioctl entry points and utility functions
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:

> From: Daniel Mack <daniel@zonque.org>
>
> 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@zonque.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


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




\
 
 \ /
  Last update: 2014-10-30 05:21    [W:0.106 / U:1.156 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site