On Wed, Jul 06, 2016 at 07:18:14AM -0600, Bob Beck wrote: > ok beck@ > > On Wednesday, 6 July 2016, Todd C. Miller <[email protected]> wrote: > > > On Wed, 06 Jul 2016 06:53:06 -0600, "Todd C. Miller" wrote: > > > > > Is there any reason to not do the check higher up in domknodat()? > > > A mknod of -1 on ffs results in a device of major 0, minor 0 which > > > is unexpected. > > > > The following should be sufficient and not interfere with creating > > FIFOs or badsect(8). > > > > - todd > > > > Index: sys/kern/vfs_syscalls.c > > =================================================================== > > RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v > > retrieving revision 1.260 > > diff -u -p -u -r1.260 vfs_syscalls.c > > --- sys/kern/vfs_syscalls.c 3 Jul 2016 04:36:08 -0000 1.260 > > +++ sys/kern/vfs_syscalls.c 6 Jul 2016 13:01:57 -0000 > > @@ -1228,6 +1228,8 @@ domknodat(struct proc *p, int fd, const > > if (p->p_fd->fd_rdir) > > return (EINVAL); > > } > > + if (dev == VNOVAL) > > + return (EINVAL); > > NDINITAT(&nd, CREATE, LOCKPARENT, UIO_USERSPACE, fd, path, p); > > nd.ni_pledge = PLEDGE_DPATH; > > if ((error = namei(&nd)) != 0) > > > > Yep, that was my first reaction, but I thought there might be a reason for it.
That's so much more reasonable then. Note: it seems strange to have extra checks for VT_CHAR... in tmpfs_mknod as well. These should be fs-independent ?...
