🚀 go-pugleaf

NOTE: This is in response to an article in net.bugs, asking for an
      eaccess() system call to check permissions based on effective
      user- and group-ids. I've added net.unix-wizards to the news
      group list, since it belongs there, but shouldn't be stranded
      from the original article.

Rather than another application-specific system call, how about a
more general solution:

	int permiss(path, uid, gid)
	char	*path;
	int	uid;
	int	gid;

Permiss() determines filesystem permissions to 'path' by user 'uid' in
group 'gid'. Returns a value built up from 04 for read-, 02 for write-
and 01 for execute-access.

Permiss() could even replace access(), with a compatibility function
in libc:

extern int
access(path, mode)
char	*path;
int	mode;
{
	return ((permiss(path, getuid(), getgid()) & mode) == 0 ? -1 : 0);
}

This is still a partially-baked idea, but I believe it to be "cleaner"
than access(), and preferable to adding yet another system call.

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

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

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.

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.

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.
					Kenneth Almquist