🚀 go-pugleaf

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.
|> 
|> I ask, because it is annoying to ship tar archives to other sites and
|> require the recipient to be super-user to extract the files, but in
|> general that seems to be necessary.  (n.b. rebuilding the kernel is a
|> bit much to ask the recipient).  Is there another solution short of
|> running homogeneous networks?
|> 
|> Ken

I happened to encounter the problem once before, and the way I did to
go around it was to login to a SGI machine(obviously, this
SGI box has to have access to that SGI bound disk) to do the untar.
Normaly it works because the user who has the access to the SGI bound disk
should have access to some SGI machines that accesses the disk, and is
easier than rebuilding the kernel, not to mention you may not always have the
source. I would be very interested to know who should be blamed for 
the problem, though.

Tom
-- 
---------------------------------------------------------------------------
|-                                                                       -|
|-- tzheng@cs              Room: CS G016        O.Phone: (317)494-0813  --|
---------------------------------------------------------------------------

>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.
>|> 
   Gnu has "gtar" that takes care of it.
--
James A. Ertle                       |... but she's being so
ertle@{hal|sal|kira|griffin}.uvm.edu |DIFFICULT!!!
UVM's EMBA Computer Facility         |		- The Beast
Burlington, Vt. USA                  |	

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

In <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.
| 
| I ask, because it is annoying to ship tar archives to other sites and
| require the recipient to be super-user to extract the files, but in
| general that seems to be necessary.  (n.b. rebuilding the kernel is a
| bit much to ask the recipient).  Is there another solution short of
| running homogeneous networks?

It is basicly because tar was written under V7 unix where only
the superuser could give files away, and it seemed silly to add
a check in tar to see if you were superuser.  When the S3/S5
versions of unix decided that they didn't like that model, a number
of things broke, including tar.  More recent versions of tar do
the check to see if you are superuser, as some other postings
mentioned.

By the way, the problem only occurs when directories are created,
in most cases, since the chown is done after the file is extracted,
and therefore there are no problems with regular files.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com