Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: ftruncate broken? - Sun-based NFS
Message-ID: <1890@auspex.auspex.com>
Date: 10 Jul 89 18:58:01 GMT
References: <1579@mcgill-vision.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 32

>The problem is that ftruncate() fails if the file modes prohibit
>Anybody have a simple fix?  (Patch a couple of bytes to noops somewhere
>in the OBJ/ files perhaps?)

Sure, you can probably no-op out the code in "ufs_setattr" that calls
"iaccess" to check whether you have write permission.  Of course, this
would let you make NFS RPC calls directly to truncate files to which you
don't have write access, which I suspect you don't want....

>Will it be fixed in newer releases (4.x)?

It's not fixed in 4.0; I've noted the problem to somebody at Sun.  The
problem is that truncating a file should be treated like writing it -
i.e., the permission checks should be made:

	1) at the system call layer (which is already done for both
	   calls)

and

	2) at the NFS server layer (which is already done for "write"
	   but not for "setattr" setting the length)

but *not* at the UFS layer.

I can't see any problems with making the requisite changes (i.e., get
rid of the "iaccess()" call in "ufs_setattr", put in a VOP_ACCESS call in
"rfs_setattr" - i.e., in the server code - if you're trying to set the
size, and make sure there are no *other* calls to VOP_SETATTR that might
set the size and that are relying on the underlying file system to do
any permissions checking), but that doesn't mean no such problems exist,
so be careful.