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
jik@athena.mit.edu (Jonathan I. Kamens) (03/04/91)
In article <21795@yunexus.YorkU.CA>, oz@yunexus.yorku.ca (Ozan Yigit) writes: |> 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. Look. You asked a question, and I gave you an answer quoted from a man page. The answer describes both how my system *claims* it behaves, and how I think it *should* behave. I'm not going to try to explain all over again in comp.unix.wizards why I think the setuid and setgid bits should be cleared upon write even when the file in question isn't executable. I have already explained that at length in comp.unix.shell, and people who are interested in reading my justification can do so there. |> Say, brain-damage ;-), or could there possibly be another reason for it? Yes, I'd say brain-damage. As I said in my postings in comp.unix.shell, I do not believe it is ever possible to be sure that a system is free of any security holes. I do not believe there is any way we can know in the foreseeable future that there definitely isn't some security hole in a system that would allow a user to make a file that isn't executable executable, while it would not allow him to make a file that isn't setuid setuid. Given the impossibility knowing that, it seems to me that it is reasonable to disable the setuid and setgid bits on writes to files that are not executable. I've explained all of this in comp.unix.shell. |> Ah, a sufficiently detailed, didactic paragraph that just happens to be |> erroneous given certain chmod semantics. See your chmod(2) for details. Look, Ozan, if you want to tell me I'm wrong, then tell me I'm wrong, and tell me why I'm wrong. I am quite familiar with chmod(2) man page, and I don't know what you're talking about. So, rather than sitting on your high horse and acting like you're so much better than I am that I don't even deserve a straightforward explanation of what you're talking about, why don't you just tell me what you're talking about. When civilized people discuss things in a way that is meant to promote mutual understanding and eventual agreement, they say what they mean, rather than making vague allusions that they think make them look better. |> [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.] Once again, I don't see what this has to do with the discussion. If you're willing to explain it, please do so. Otherwise, you don't seem to be adding anything useful to the discussion. Incidentally, this discussion started out talking about Unix in general, something which POSIX definitely is not, considering that the vast majority of Unix systems out there nowadays are nowhere near POSIX compliant. If we're going to talk about securite on Unix systems in general, POSIX is only one fish in the sea, and it's a big sea. Referring to POSIX as if it proves your point is therefore a red herring. |> Let me ask again: what is it that you know to be broken? Let me quote from the portion of my response which you *omitted* in yours. "I can't tell whether or not you're being sarcastic here, but let me clue you in on something -- I was." Understand, Ozan? You asked me to explain why I said POSIX was broken. In my response, I ADMITTED THAT I WAS BEING SARCASTIC. And yet you ignore that in your response. And, of course, many of the people seeing your posting don't know that, because they didn't see the start of the discussion in comp.unix.shell. Such honest, upright behavior, quoting only part of my posting and distorting my point completely. Now, as I said in my last posting, ONE THING I consider broken about POSIX is that it's not possible to find out how much space a file takes up on the disk. I didn't say that POSIX in general is broken, I said that I consider that particular deficiency to be ONE BIT OF BROKENNESS. Now, you can (and have) post pretty phrases talking about how one deficiency does not a broken system make, or about how it has not yet been shown that the missing st_blocks is in fact bad. And that may be true. But that is your OPINION. It is my OPINION, on the other hand, that the lack of st_blocks is brokenness. And once we get down to your opinion versus mine, Ozan, I see no reason to discuss this particular portion of our disagreement any further. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710