Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site laidbak.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!clyde!ihnp4!laidbak!mark
From: mark@laidbak.UUCP (Mark Brukhartz)
Newsgroups: net.bugs,net.unix-wizards
Subject: Re: Usefulness of access(2) - (nf)
Message-ID: <173@laidbak.UUCP>
Date: Mon, 26-Sep-83 02:10:59 EDT
Article-I.D.: laidbak.173
Posted: Mon Sep 26 02:10:59 1983
Date-Received: Wed, 28-Sep-83 06:30:06 EDT
References: <2916@uiucdcs.UUCP> <172@laidbak.UUCP>, <495@spanky.UUCP>
Organization: LAI, Westmont, IL
Lines: 33

In response to spanky!ka, regarding a proposed replacement for access(2):

	I see little need for a function to check for access permission on a
	file by the effective user/group id.  Simply doing a stat(2) on the
	file will achieve the same result.

An eaccess(2) has been proposed to check access by effective user- and group-
ids. Rather than adding another single-purpose system call, I'd rather replace
access(2) with a more general case. There would, of course, be a compatibility
function in libc. Note that stat(2) doesn't check parent directory permissions.

	The problems with the proposed pathaccess system call are twofold.
	First, it would require a lot more work to implement than access.
	Access simply resets the effective id's temporarily and calls nami
	to check the permissions; the proposed new call would have to do its
	own path search.

I didn't say that it would be easy [:-)].

	The second problem has to do with security. Access will perform a
	directory search even if the effective user id doesn't have execute
	permission on a directory. In the case of the more general call, care
	would have to be taken to ensure that such searches didn't create a
	security hole.

Now things become messier. Directory access would have to be restricted by
the effective user- and group-ids of the invoker. This would break access()
when a component directory can by "executed" by the real user- and group-ids,
but not the effective ones. Perhaps this would all be easier with stacked
user- and group-ids, but that "improvement" has been argued already. Oh, well...

				Mark Brukhartz
				..!{allegra,ihnp4,ittral,trsvax}!laidbak!mark