cpio -itv < problems

[Adri Verhoef]

Hiya,
  a few months ago I posted a problem involving 'cpio':
'cpio' does not work when it cannot open one of its parent directories.

	Repeat-by:
		$ id
		uid=104(ccea3) gid=101(cce)
		$ cd /usr/tmp
		$ mkdir tst1; cd tst1
		$ mkdir tst2; cd tst2
		$ chgrp bin ..
		$ chown bin ..
		$ pwd
		/usr/tmp/tst1/tst2
		$ touch bugs.cpio
		$ cpio -itv < bugs.cpio
		sh: pwd: cannot open ..
		$ ls -ld . ..
		drwxr-x---   2 ccea3    cce           32 May 31 22:04 .
		drwxr-x---   3 bin      bin           48 May 31 22:04 ..


Our vendor finally replied, saying:
       Brief Problem Description : cpio does work correctly when it cannot
				   open it parent directory.

       Reply : It is the natural feature of sh. This feature will be taken into
	       consideration in the new release of sh.


The real question was:
Why do some programs use getcwd(3C) in cases that they really don't need to,
or why don't they try to recover from a getcwd(3C) error if it is not really
important to know where we are.

mcvax!vsedev.VSE.COM!logan (James Logan III) replied:
>how often does someone lock the door behind them without having a
>key to get back out? :)  

We do have a certain application that does run under certain privileges,
for that matter.

>In answer to your question about why certain programs call
>getpwd(), Perhaps AT&T is trying to make it more difficult to do
>anything useful in the above scenario, which is a mild security
>violation.  (I say mild because the directory contents couldn't
>have been too sensitive if you had access just a moment before.) 
>
>			Jim


	Regards, Adri Verhoef, mcvax!rivm!a3.