| From | (Eric W. Biederman) | Date | Wed, 29 Oct 2014 20:50:33 -0700 | Subject | Re: 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
|