From rhh@ct.picker.com  Mon Jan 26 15:24:15 1998
Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA19330
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 26 Jan 1998 15:24:11 -0800 (PST)
          (envelope-from rhh@ct.picker.com)
Received: from ct.picker.com by whqvax.picker.com with SMTP;
          Mon, 26 Jan 1998 18:23:26 -0500 (EST)
Received: from stealth.ct.picker.com (eagle.ct.picker.com) by ct.picker.com (4.1/SMI-4.1)
	id AA07335; Mon, 26 Jan 98 18:23:23 EST
Received: (from rhh@localhost)
	by stealth.ct.picker.com (8.8.8/8.8.8) id SAA01299;
	Mon, 26 Jan 1998 18:25:02 GMT
	(envelope-from rhh)
Message-Id: <199801261825.SAA01299@stealth.ct.picker.com>
Date: Mon, 26 Jan 1998 18:25:02 GMT
From: rhh@ct.picker.com
Reply-To: rhh@ct.picker.com
To: FreeBSD-gnats-submit@freebsd.org
Cc: rhh@ct.picker.com
Subject: mount_msdos won't run setuid-root
X-Send-Pr-Version: 3.2

>Number:         5575
>Category:       bin
>Synopsis:       mount_msdos won't run setuid root
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 26 15:30:00 PST 1998
>Closed-Date:    Fri Apr 17 12:27:22 PDT 1998
>Last-Modified:  Fri Apr 17 12:30:46 PDT 1998
>Originator:     Randall Hopper
>Release:        FreeBSD 3.0-971208-SNAP i386
>Organization:
self
>Environment:

        Stock 3.0-971208-SNAP system

>Description:

	The topic pretty well says it all.  Users of machines with shared
	resources such as floppy and ZIP disk drives shouldn't have to
	be given root to mount these removable media.  

	Also for users of dedicated FreeBSD machines, it is more convenient
	for users not to have to su to root to mount removable media.

>How-To-Repeat:

     This Perl script demonstrates the problem.  UFSs will mount fine
     setuid root.  DOS FAT FSs won't.  Change /dev/sd0s4 to the path
     of any FAT slice:

          #!/usr/bin/suidperl -w
     
          $ENV{'PATH'}  = '/bin:/usr/bin:/usr/sbin:/sbin';
          $ENV{'SHELL'} = '/bin/sh' if defined $ENV{'SHELL'};
          $ENV{'IFS'}   = ''        if defined $ENV{'IFS'};
          
          chdir( "/" );
          ( !system( "mount /dev/sd0s1 /zip"       ) 
                  && print "UFS /zip mounted\n" ) ||
          ( !system( "mount -t msdos /dev/sd0s4 /zip" ) 
                  && print "DOS /zip mounted\n" ) ||
           
          die "Mount failed\n";

>Fix:
	
	The best solution might be for FreeBSD to implement a mechanism
	for granting mount access to groups on a per-device basis.

	Short of that though, all mount commands should be accessible through
	setuid scripts, and access control can be implemented via the 
	ownership and permissions on these mount scripts.

        Presently no work-around known on 3.0-current.  Must su to mount 
        FAT partitions.

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
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

From: Randall Hopper <rhh@ct.picker.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/5575: mount_msdos won't run setuid-root
Date: Wed, 28 Jan 1998 17:07:03 -0500

 Bruce Evans:
  |Randall Hopper:
  |>Synopsis:       mount_msdos won't run setuid root
  |>
  |>	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.
 
 Thanks for the detailed explanation.  I wasn't aware of these.
 
 Ok, so sounds like the bug report issue is still valid, but my suggested
 fix was off.  Access control hasn't been fully implemented across the board
 yet, resulting in neither euid root or euid = mount point uid being
 sufficient to mount_msdos.
 
 Thanks,
 
 Randall
State-Changed-From-To: open->closed 
State-Changed-By: dt 
State-Changed-When: Fri Apr 17 12:27:22 PDT 1998 
State-Changed-Why:  
Access control has been fixed for msdosfs. 
>Unformatted:
