Quoting Miklos Szeredi (miklos@xxxxxxxxxx): > > > From: Miklos Szeredi <mszeredi@xxxxxxx> > > > > > > Add a new filesystem flag, that results in the VFS not checking if the > > > current process has enough privileges to do an mknod(). > > > > > > This is needed on filesystems, where an unprivileged user may be able > > > to create a device node, without causing security problems. > > > > > > One such example is "mountlo" a loopback mount utility implemented > > > with fuse and UML, which runs as an unprivileged userspace process. > > > In this case the user does in fact have the right to create device > > > nodes within the filesystem image, as long as the user has write > > > access to the image. Since the filesystem is mounted with "nodev", > > > adding device nodes is not a security concern. > > > > Could we enforce at do_new_mount() that if > > type->fs_flags&FS_MKNOD_CHECKS_PERM then mnt_flags |= MS_NODEV? > > Well, the problem with that is, there will be fuse filesystems which > will want devices to work Crud, sorry, I forgot all fuse filesystems will have the same fs_flags. > and for those the capability checks will be > reenabled inside ->mknod(). In fact, for backward compatibility all > filesystems will have the mknod checks, except ones which explicitly > request to turn it off. > > Since unprivileged fuse mounts always have "nodev", the only way Ah yes, I'd forgotten that we do if (!capable(mknod)) mnt_flags |= MNT_NODEV No objections then anyway. Thanks for indulging me :) > security could be screwed up, is if a filesystem running with > privileges disabled the mknod checks. > > I will probably add some safety guards against that into the fuse > library, but of course there's no way to stop a privileged user from > screwing up security anyway. Agreed. > If for example there's a loop mount, where the disk image file is > writable by a user, and root mounts it without "nodev", the user can > still create device nodes (by modifying the image) even if the mknod > checks are enabled. thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
