From owner-freebsd-bugs Tue Jan 27 21:30:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA20863 for freebsd-bugs-outgoing; Tue, 27 Jan 1998 21:30:05 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: (from gnats@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA20843; Tue, 27 Jan 1998 21:30:02 -0800 (PST) (envelope-from gnats) Date: Tue, 27 Jan 1998 21:30:02 -0800 (PST) Message-Id: <199801280530.VAA20843@hub.freebsd.org> To: freebsd-bugs Cc: From: Bruce Evans Subject: Re: bin/5575: mount_msdos won't run setuid-root Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/5575; it has been noted by GNATS. From: Bruce Evans To: FreeBSD-gnats-submit@FreeBSD.ORG, rhh@ct.picker.com Cc: Subject: Re: bin/5575: mount_msdos won't run setuid-root Date: Wed, 28 Jan 1998 16:10:26 +1100 > The best solution might be for FreeBSD to implement a mechanism > for granting mount access to groups on a per-device basis. It already does. Access is controlled by: 1) ownership of the mount point. If the euid of the caller is not root, then the uid of the mount point must match this euid. This is enforced by kern/vfs_syscalls.c:mount(). 2) appropriate permissions on the device or file system being mounted. For devices, the appropriate permissions are read-write access to the device. Support for this is missing in ffs and ext2fs, and broken in msdsofs. These file systems still do things in the pre-Lite2 way, which is to depend on kern/vfs_syscalls.c:mount() doing everything and hack around it doing too much for msdosfs. The msdosfs hack now conflicts with (1). 3) The vfs.usermount sysctl. Since access control is mostly broken, vfs.usermount defaults to 1 so that access control almost reverts to the pre-Lite2 model. Bruce