[net.bugs.4bsd] bugs in access

spaf@gatech.CSNET (Gene Spafford) (06/06/85)

I have found what I believe to be a few bugs in the access(2) routine.
Before I go about trying to put in fixes, I'd like to know if others
have found these bugs and already have fixes.  I'd also like to
know if anyone can think of anything that will break if I fix these.

For indexing purposes, we're running the BRL 3.0 release of their
version of 4.2 BSD.  "access" is in /sys/sys/ufs_fio.c

Bug #1)  A call to "access" root" with multiple permission checks
on a file on a read-only disk will return an incorrect result.

Example:
	i = access("/ro/foo", 022)
	and foo is on a read-only disk, the routine returns a 0
	(implied "true").
Probable fix:
	change the line near the beginning which has
		if (m == IWRITE)
	to
		if ((m & 0222) != 0)


Bug #2)  Root is shown as having "execute" access to everything.
	 This isn't correct for files which are not executable.

Probable fix:  Basically, the code which is currently:
	/*
	 * If you're the super-user,
	 * you always get access.
	 */
	if (u.u_uid == 0)
		return (0);

	should be rewritten to be something like:

	if (u.u_uid == 0)
	{
	    if (ip->i_mode&IFMT == IFDIR)
		    return (0);
	    else
	    {
		if (ip->imode&0111 != 0)
			return (0);
		else
		{
		    u.u_error = EACCES;
		    return (1);
		}
	    }
	}



Comments?
-- 
Gene "3 months and holding" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet:	Spaf @ GATech		ARPA:	Spaf%GATech.CSNet @ CSNet-Relay.ARPA
uucp:	...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf

guy@sun.uucp (Guy Harris) (06/16/85)

> Bug #1)  A call to "access" root" with multiple permission checks
> on a file on a read-only disk will return an incorrect result.
> 
> Example:
> 	i = access("/ro/foo", 022)
> 	and foo is on a read-only disk, the routine returns a 0
> 	(implied "true").

"access" is always called with IREAD, IWRITE, or IEXEC as its second
argument; it shouldn't be called with a mode like 022, as it shifts the mode
right by 0, 3 or 6 positions, depending on whether you're the owner, not the
owner but in the group that owns the file, or none of the above.

> Bug #2)  Root is shown as having "execute" access to everything.
> 	 This isn't correct for files which are not executable.

In V6, the super-user didn't have execute access unless the appropriate
execute bit was set.  This was changed before V7 came out, so that the
super-user would have search permission on all directories.  In both 4.2 and
S5R2, the "exec" system call requires "access(ip, IEXEC)" to return 0,
requires that the file be a plain file, *and* requires that at least one of
the execute permission bits be set; since the code is almost identical, I
assume that this dates back to when the change was made.  As such, root has
execute access to all files which are executable; this requires that
somebody must have execute permission on the file, so even "root" can't
execute a file with mode rw-r--r--, for instance.

	Guy Harris