🚀 go-pugleaf

In article <1ggu1sINNp8q@guinan.cs.purdue.edu>, tzheng@cs.purdue.edu (Tom Zheng) writes:
|> 
|> In article <Bz882q.L2.2@cs.cmu.edu>, cline+@cs.cmu.edu (Kenneth Cline) writes:
|> |> A user logged into a Sun4 was unable to extract tarred files (created
|> |> by another user) to a disk mounted on our SGI machine.  Apparently,
|> |> SunOs tar chowns the new file to the old user before reading its
|> |> contents, and subsequent operations fail due to ownership conflict.
|> |> 
|> |> The fix was to build a new kernel for the SGI with restricted_chown
|> |> set to 1.  Now, "tar x..." works fine, but I would like to know if
|> |> this is a bug in SunOs tar (maybe, calling chown prematurely), an SGI
|> |> bug (which doesn't seem as likely), or simply conflicting features.
|> |> 
|> ...
|> source. I would be very interested to know who should be blamed for 
|> the problem, though.
|> 


Blame tar. It (obviously) tries to chown to the other user and doesn't complain
if the chown fails. The Sun fs code restricts chown. The default SGI code doesn't.
Sun tar should behave like the SGI tar and only chown if invoked by the 
superuser.

Now why anyone would want an unrestricted chown is another question entirely.

-- 
_/**/Sam_Fulcomer	sgf@cfm.brown.edu	What, me panic: uba crazy
Brown University  Center for Fluid Mechanics, Turbulence  and Computation