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