Retaining file permissions

[Jonathan I. Kamens]

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.  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 at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710