Path: utzoo!mnetor!uunet!munnari!moncskermit!goanna!yabbie!koel!rcodi
From: rcodi@koel.rmit.oz (Ian Donaldson)
Newsgroups: comp.bugs.sys5
Subject: Re: A security hole
Message-ID: <388@koel.rmit.oz>
Date: 4 Mar 88 06:02:28 GMT
References: <181@wsccs.UUCP>
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 24

in article <181@wsccs.UUCP>, terry@wsccs.UUCP (terry) says:
> 	Do NOT write a setuid program that uses getcwd().  The getcwd() call
> does a popen() of the "pwd" shell command and does not check it's path.  This
> means that someone could write their own pwd and execute the command from
> their directory, thus gaining root access via a sh -c.

This would be a hole if your system had the BSD /bin/sh, but in the SVR2
/bin/sh, the "pwd" command is a built-in and always executes the same way 
regardless of any PATH setting or the contents of the current directory.  

Since SVR2 getcwd() just takes the output of popen("pwd") it is safe in
-that- regard.  There might of course be other security holes lurking 
though.. since you -are- invoking a shell.

[So much for the concept of "keeping the shell simple and small"...]

In the BSD /bin/sh, pwd is not a built-in, and you would receive the
described behaviour.  But in BSD the equivalent to SVR2 getcwd(3) is 
getwd(3), and this doesn't use popen(3) or /bin/sh, so doesn't have 
this problem.  Its also much much faster.  Try issuing the SVR2 getcwd()
function from a program that has a 4Mb data segment and you will see
what I mean (on systems that don't have copy-on-write fork()'s).

Ian D