Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!okstate!uokmax!rmtodd
From: rmtodd@uokmax.UUCP (Richard Michael Todd)
Newsgroups: comp.os.minix
Subject: Re: SETUID problems with mkdir & rmdir
Message-ID: <630@uokmax.UUCP>
Date: Tue, 21-Jul-87 23:16:09 EDT
Article-I.D.: uokmax.630
Posted: Tue Jul 21 23:16:09 1987
Date-Received: Fri, 24-Jul-87 00:50:12 EDT
References: <341@louie.udel.EDU> <8308@utzoo.UUCP>
Reply-To: rmtodd@uokmax.UUCP (Richard Michael Todd)
Organization: University of Oklahoma, Norman
Lines: 37
Summary: forbidden() is broke

In article <8308@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>Sorry, no, you have misunderstood the fine points of setuid bits and the
>access() system call.  The access() call checks permissions against the
>"real" userid and groupid, which are *not* changed by the setuid bit.
>This is the way it works in V7 and true V7-compatible systems, anyway.
Alas, MINIX access() is broke in a couple of ways.  The problems lie in the
forbidden() routine in the file server, which is supposed to check for given
types of access against either real or effective uid, depending on a flag
passed to the function.  It is called by do_access to check against real
uid, and everywhere else to check against euid.
  Problem 1:  forbidden() should grant all access to the file if the uid
being checked against (real or effective, depending on the flag) is 0.
Alas, the code to do this takes the easy way out,testing a global flag:
	if (super_user) { 		(line 11800 of the book)
		perm_bits = 07;
	} else {...
and this flag is set whenever euid==0.  Since mkdir and rmdir always run
as euid==0, this allows them access to everything.
  Problem 2:  forbidden, to check if a file is accessible in a certain mode,
has to have access to the inode data for the file.  (Forbidden's first
arg. is a pointer to the inode struct for the file being checked).  To get
the inode pointer for a given filename, the caller has to first call eat_path.
Eat_path has to look in the various directories specified in the pathname,
checking each step of the way if the directory is searchable.  The checks
are always done against effective uid.  This is not quite correct.  If
we do an access("/foo/bar",2), our real uid is not root and our euid is,
if our real uid won't allow us execute (search) permission for /foo, the
access call should fail.  It will succeed.  (Admittedly these circumstances
are rather unusual, but it is nonetheless a bug, and one that would be a bit
tricky to fix.)
>Making mkdir and rmdir owned by root with the setuid bit on is precisely
>the right thing to do, unless Minix has done something bizarre.
Not bizarre, just broken.
--------------------------------------------------------------------------
Richard Todd
USSnail:820 Annie Court,Norman OK 73069
UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd