Retaining file permissions

[Ozan Yigit]

[this discussion is no longer relevant to comp.unix.shell. see followup]

In article <see ref> jik at athena.mit.edu (Jonathan I. Kamens) writes:
>In article <21789 at yunexus.YorkU.CA>, oz at yunexus.yorku.ca (Ozan Yigit) writes:
>|> In article <see ref> jik at athena.mit.edu (Jonathan I. Kamens) writes:
>|> >  You must have a pretty strange version of cat on your system, or a
>|> >brain-damaged kernel that does not clear the setuid bit when a file is written
>|> >to.
>|> Any file, or just those files that are also executable?

>  From write(2):
	[a fragment of write man page related to suid-bit clearing]

That man page portion probably dates to 4.2BSD, and unfortunately fails to
explain to you [nor answer] the point I was trying to make. Sure enough,
your example of setting suid bit of an ordinary (non-executable) file and
how write clears that suid bit will not work on on many systems, although
you may [sometimes] find the very same write man page on those systems.

Say, brain-damage ;-), or could there possibly be another reason for it?

>  If it only did it on executable files, then if there were a file on the disk
>that was setuid but not executable, a not-nice person could (a) figure out
>some way to write his own program into the file, and (b) use chmod to make it
>executable.  this defeats the purpose of the clearing of the set-user-id bit.

Ah, a sufficiently detailed, didactic paragraph that just happens to be 
erroneous given certain chmod semantics. See your chmod(2) for details.

[I trust someone with enough involvement in the POSIX 1003.1/.n will
describe the treatment/rationale of S_ISUID and S_ISGID bits under various
conditions.]

>|> >If that
>|> >isn't in the standard, then the standard is broken; then again, we already
>|> >knew that, so it isn't a surprise.
>|> Really? How about a list of all those things you already knew to be
>|> broken in the standard? I am much interested.

>	      ... one thing I consider broken about POSIX is that there's no
>st_blocks field in its stat structure; more generally, there is no standard
>way in POSIX to find out how much space a file actually occupies on the disk
> ...

Interesting consideration, though I fail to see why this amounts to POSIX
being broken. I take ``broken'' to mean internally inconsistent, or simply
erroneous, and instead you present your views on something that is not a
part of the standard [along with many other things] and is yet to be shown
indispensible within the its scope. If a strong argument could be made for
such a thing, that would make POSIX incomplete, [which may, as often
happens with other standards, be completed via implementation agreements
or other supplements] but not necessarily broken.

Let me ask again: what is it that you know to be broken?

oz
---
We only know ... what we know, and    |   Internet: oz at nexus.yorku.ca 
that is very little. -- Dan Rather    |   UUCP: utzoo/utai!yunexus!oz