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