Xref: utzoo comp.unix.shell:1594 comp.unix.wizards:24317 comp.unix.internals:2199 Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!oz From: oz@yunexus.yorku.ca (Ozan Yigit) Newsgroups: comp.unix.shell,comp.unix.wizards,comp.unix.internals Subject: Re: Retaining file permissions Keywords: chmod, sed, awk... and good old *cat*! Message-ID: <21795@yunexus.YorkU.CA> Date: 1 Mar 91 18:34:52 GMT References: <6039@ptsfa.PacBell.COM> <1991Feb22.041826.201@athena.mit.edu> <1991Feb23.234242.812@am.sublink.org> <1991Feb26.153931.27251@athena.mit.edu> <21789@yunexus.YorkU.CA> <1991Feb28.205734.26484@athena.mit.edu> Sender: news@yunexus.YorkU.CA Followup-To: comp.unix.wizards Organization: York U. Communications Research & Development Lines: 59 [this discussion is no longer relevant to comp.unix.shell. see followup] In article jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <21789@yunexus.YorkU.CA>, oz@yunexus.yorku.ca (Ozan Yigit) writes: >|> In article 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