jim@baroque.Stanford.EDU (James Helman) (07/31/90)
Unlike BSD/SunOS, IRIX tar religiously obeys the directory modes defined in an archive. This means that if you restore an archive which contains write-protected directories, tar is unable to write any part of the archive beneath that point (unless one is root). One solution is repeatedly untar and unprotect the offending directories, but this could take many iterations if the protected tree is deep. There must be a better way, but I don't see any flags that help. In a similar vein (i.e. IRIX tar shooting itself in the foot), something which bugs the bejesus out of me is tar's restoring directory/file ownerships for normal users. Why should normal users need or even be able to create files and directories they don't own? This usually means that tar then fails to retrieve the requested files because of protection mismatches as above. In addition, if the protections on what they just restored are restrictive, they may even have to call a rotorooter to remove the directory! Of course the "-o" flag will save you, but why leave an open hole for novice or BSD-acclimated users to trip into? b'roke> id uid=31(guest) gid=31(guest) b'roke> tar tvf enough.tar r-xr-xr-x 13/11 dir Jul 30 14:55 1990 enough/ rw-r--r-- 13/11 0 Jul 30 14:54 1990 enough/already rw-r--r-- 13/11 0 Jul 30 14:54 1990 enough/irepent rw-r--r-- 13/11 0 Jul 30 14:54 1990 enough/juststop rw-r--r-- 13/11 0 Jul 30 14:55 1990 enough/please rw-r--r-- 13/11 0 Jul 30 14:55 1990 enough/youtwit b'roke> tar xf enough.tar tar: enough/already - cannot create tar: enough/irepent - cannot create tar: enough/juststop - cannot create tar: enough/please - cannot create tar: enough/youtwit - cannot create b'roke> rmdir enough rmdir: enough: Search or write permission needed Yeeech! Jim Helman Department of Applied Physics 6 Trillium Lane Stanford University San Carlos, CA 94070 (jim@KAOS.stanford.edu) (415) 723-9127
guy@auspex.auspex.com (Guy Harris) (08/01/90)
>Of course the "-o" flag will save you, but why leave an open hole for >novice or BSD-acclimated users to trip into? System V compatibility, presumably. It wasn't SGI's idea, it was AT&T's (V7, and thence BSD, disallowed giving files away - actually, it dates back before V7; PWB/UNIX 1.0, and thence ... and thence S5, lets a user give a file away); the most you can flame them for is not changing "chown()" nor "tar", and if they had, somebody else would have flamed them for incompatibility.... At least S5R4 lets you configure your system to disallow giving files away (good idea, given that its 4.3BSD file system supports quotas...).
olson@anchor.esd.sgi.com (Dave Olson) (08/01/90)
In <JIM.90Jul30150137@baroque.Stanford.EDU> jim@baroque.Stanford.EDU (James Helman) writes: | Unlike BSD/SunOS, IRIX tar religiously obeys the directory modes | defined in an archive. This means that if you restore an archive | which contains write-protected directories, tar is unable to write any | part of the archive beneath that point (unless one is root). One | solution is repeatedly untar and unprotect the offending directories, | but this could take many iterations if the protected tree is deep. | There must be a better way, but I don't see any flags that help. | | In a similar vein (i.e. IRIX tar shooting itself in the foot), | something which bugs the bejesus out of me is tar's restoring | directory/file ownerships for normal users. Why should normal users | need or even be able to create files and directories they don't own? | This usually means that tar then fails to retrieve the requested files | because of protection mismatches as above. In addition, if the | protections on what they just restored are restrictive, they may even | have to call a rotorooter to remove the directory! Of course the "-o" | flag will save you, but why leave an open hole for novice or | BSD-acclimated users to trip into? | This one has been pretty well beat to death. The issue is that SysV allows users to chown files to someone else (stripping setuid, etc. if not the superuser). Many religous arguments have been carried out about this, but that is the way things are. Tar has always (even on V7/BSD/SunOS) tried to chown the files and directory away, but silently fails if you aren't the superuser. One could certainly argue (and many have) that the o option ought to be the default on Sys V. It is unlikely that this will change, so I would suggest simply aliasing tar to always use the 'o' option. The o option was added to system V tar because whoever ported it at least recognized the problem (and clearly felt that giving files away by default was good, or at least was less work, we may never know which). -- Dave Olson Life would be so much easier if we could just look at the source code.