A security hole

[terry]

In article <722 at rivm05.UUCP>, Martien F v Steenbergen writes:
> First of all, by writing a setuid program you automatically open
> the security hole and you are likely to fall in. You must always
> be suspicious of any setuid program.

	Not if you program it correctly.  The point was that the security was
not checked by specification of the execution path, and it should have been,
as getcwd() is a library routine.

> Second, when you really need a setuid program you'll have to check a lot
> of permissions etc. yourself. One system call was created to help you with
> access permissions: access(2). access(2) uses the real user IDs instead
> of the effective user IDs when checking access permissions. (Remember that
> a setuid program only changes the effective user ID of the calling process.)

	The access() call is a kludge.  I could do that anyway with the
following:

	system( "/bin/sh -c <command>");

	Where <command> is the command I want run with the _real_ UID and GID.
Remember that the child inherits the parents effective as it's real, if it's
done this way.  This is helpful for running things which make sure you're
root before they will run.

> ___________________________MSDOSN'T_____________________________

I can't argue with you here... :-)

				Terry Lambert
				terry at wsccs