oz@yunexus.yorku.ca (Ozan Yigit) (03/02/91)
[this discussion is no longer relevant to comp.unix.shell. see followup] In article <see ref> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <21789@yunexus.YorkU.CA>, oz@yunexus.yorku.ca (Ozan Yigit) writes: >|> In article <see ref> jik@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@nexus.yorku.ca that is very little. -- Dan Rather | UUCP: utzoo/utai!yunexus!oz