On Mon, Jan 18, 2016 at 06:05:31PM +0100, Alexandre Ratchov wrote: > On Mon, Jan 18, 2016 at 01:35:46PM +0100, Sebastien Marie wrote: > > On Mon, Jan 18, 2016 at 12:55:30PM +0100, Alexandre Ratchov wrote: > > > > I am unsure about returning 0 for something we know is wrong to do. > > heh, it's not wrong; disconnecting audio devices is a legitimate > use of them ;)
I didn't want to said that the operation in a whole is wrong, but that making pledge_ioctl() returning 0 would be wrong as we know the operation shouldn't be allowed in normal case. > > Isn't possible to return an error ? As example, calling > > ioctl(TIOCGWINSZ) on no-tty device return ENOTTY. > > > > Agreed, and it's same for chardevs: the ioctl syscall returns > uncondionnaly ENOTTY on disconnected devices: sys_ioctl() calls > vn_ioctl() which returns ENOTTY if vp->v_type == VBAD. hum ? I dunno if I was clear. Returning ENOTTY was an example. Does disconnecting audio devices makes ioctl(2) return ENOTTY ? I doubt. The return code should be the one that normal code path would return. > > There is a difference between: > > - return 0 /* let deeper processing happen */ > > - return Exxx /* early return an error */ > > - return pledge_fail() /* kill the process */ > > > > I think the good approch would be to return an error. > > > > You're suggesting to quickly return ENOTTY in pledge_ioctl(), to > avoid going through the regular code-path that returns ENOTTY > anyway? Modulo the ENOTTY error code (see previous comment), yes the purpose is to early return from pledge_ioctl(). pledge(2) permits to expose only a portion of deeper kernel code for a set of defined operations. -- Sebastien Marie
