rock-and-roll [Re: Retaining file permissions] [long]

[Ozan Yigit]

In article <1991Mar3.221358.28886 at athena.mit.edu> 
	    jik at athena.mit.edu (Jonathan I. Kamens) writes:

>In article <21795 at yunexus.YorkU.CA>, oz at 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.

Look. You should stop posting man page fragments (presumably to suggest
RTFM) unless you are absolutely sure they add something to the discussion
at hand. This one does not, as I have tried to explain. The same man page
is found on systems were the suid bits of a non-executable file are NOT
CLEARED on a write. I really do not care how your system claims to
behave.  Your example of clearing suid bits on write to non-executable
files is not universally applicable, and you suggest that if such is the
case, those systems are ``brain damaged'' (or ``broken'' if it is POSIX)
instead of considering alternative reasons.

>  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.

But you wouldn't really mind it, now, would you? ;-)

>  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.

This is true, but boring. I think you are lecturing.

>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.

This may indeed be ``reasonable'' from some perspective. But, a statement
of such a perspective is not the same thing as clearly demonstrating those
designs that have chosen a different path (possibly based on probabilistic
insignificance of examples such as yours in a system which includes a
superuser account for example) to be ``brain damaged''.

>  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.

I made my statement on the basis of your description of a system break-in
-- without any reference to any elaborate assumptions you may have made
about, say failure of chmod semantics -- where an ordinary file with setuid
bit set can be ``chmod'' to an executable file. This is clearly wrong in
the absence of additional assumptions: The effective user ids must match
for chmod to change modes.

Your elaboration of this point and assumptions regarding broken-chmod was
posted after I made my posting.

>So, rather than sitting on your high
>horse and acting like you're so much better than I am ...

If I come across that way, it is probably because I may have an allergic
reaction towards your semi-pedantic lecturing.

>|> [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. 

On the other hand, you claimed [apparently sarcastically] that if POSIX
did not specify what you thought it ought to specify, than it is broken.

you wrote [<1991Feb26.153931.27251 at athena.mit.edu>]:

| I believe POSIX mandates that, for security reasons, the setuid and setgid
| bits on a file should be cleared whenever the file is written to.  If that
| isn't in the standard, then the standard is broken; then again, we already
| knew that, so it isn't a surprise.

The reason I referred to POSIX was, [as a followup to your reference seen
above] for genuine desire to have someone else to add to the discussion.
I found that the discussion of S_ISUID and S_ISGID bits in the standard
somewhat muddled.

Here is a fragment on this issue from 1003.1/1988, Appendix B: Rationale
and Notes Pp. 248: [1]

	Implementation which use the S_ISUID bit to indicate some other
	function (for example, mandatory record locking) on non-executable
	files need not clear this bit on writing. They should clear the
	bit for executable files and any other cases where the bit grants
	special powers to processes that change the file contents.

Do you understand this? [imitating your style, further below]

>  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.

Here we go again. Are these just opinions or manifest truths ?

>Referring to POSIX as if it proves your point is therefore a red herring.

I do not think so. See [1].

>  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.

I ignored that simply because you chose to follow your sarcasm disclaimer
with statements on POSIX (re: st_blocks) that attempt to substantiate [at
least in part] the previously disclaimed statements. I chose to deal with
only those follow-up statements of technical nature.

>Such honest, upright behavior, quoting only part of my
>posting and distorting my point completely.

I don't like this at all.

I am neither dishonest, nor less than upright, as you insinuate. I did not
attempt to distort your point, at least not intentionally. In my posting I
also clearly stated where the discussion came from.

You may wish to re-post all your previous articles on this topic if you are
really concerned about such so-called distortions.

>I didn't say that POSIX in general is broken, I said that I consider
>that particular deficiency to be ONE BIT OF BROKENNESS.

You mean, like almost-pregnant? ;-)

>  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.

I'm glad you find my phrasing "pretty". I like their content better.

I did not say "deficiency". That amounts to begging the question. [Is this
considered distortion? ;-)]

I now know your statements were opinions. I merely put forth a framework
where your statements regarding <lack of st_blocks is brokenness> [where
broken is taken to mean internally inconsistent, or erroneous] do not
appear to have a rational basis. Such a rationale could be provided, but
you appearently are not equipped to do so.

I do not believe this to be a simple clash of opinions.

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