Retaining file permissions

[Donn Terry]

Submitted-by: donn at hpfcrn.fc.hp.com (Donn Terry)

In article <18296 at cs.utexas.edu> alex at am.sublink.org (Alex Martelli) writes:

>It would definitely make sense that cat a>b "do the natural thing" - IF
>the kernel must muck with permission bit on write()s to b, then it
>would hardly make sense for cat to have to undo it, and viceversa, if
>the kernel leaves b's permission bits alone, then so should cat 
>(should the SHELL try to change permission bits in the redirected-to
>file before exec'ing cat??? I would DEFINITELY hope not!).  I have
>redirected followups to comp.std.unix since it seems more of a standard
>related question.  So, what DOES Posix say about this (open(), write(),
>cat, shell redirection, and permission bits), and what SHOULD it say?

POSIX.2 (where cat is discussed) is silent on the subject, because it
relies on the underlying system behavior, which doesn't have to be
POSIX.1.  (It could be <your favorite absurd OS name here> as long
as some specific requirements for minimal similarity to POSIX.1 are met.)

POSIX.1 says "On a regular file, [the S_ISUID] bit should be cleared
on any write."  (P102, L684 and 688).  

Two key things here:  "should" (not "shall") and "write" (not write() in
italics). 

"Should" is a recommendation, not a requirement.  Thus, a conforming
system doesn't have to do it.  This is compromise wording, as some
existing implementations would not conform if that was a requirement.
(This is a consequence of the definition of "should".)

"Write" means any write operation, not specifically the write() system
call.  (This is a judgement call on my part, and should not be taken
as in any way official.)

There are those who would (and did) argue that it's "brain-damaged" to
clear the bit, and those who would (and did) argue the other way.

A relevant digression into the use of a standard as a tool for 
purchasing, and how it fits into this kind of problem.

If you care, it's perfectly reasonable in a RFP (or any other purchase)
to specify any "should" as a "shall" (or "shall not").  NIST did that in
one place in FIPS 151-1.  X/Open has done it in several places.  In the
long run, if a clear consensus develops that some "should" is always or
never required, the standard can change to make it a "shall" or "shall
not".  (Someone has to care enough to make that happen during the
next revision, but if the consensus is there, it's not hard.)

When you specify a bunch of options, it can be called a "profile".
There is work on both de-facto standard profiles (X/Open and NIST
qualify here) and on formal ones (IEEE 1003.<several>).  Since profiles
can often be "lighter weight" documents than a typical POSIX standard,
some of the should/shall issues can be addressed in them more rapidly
than in the base standards.  (This might be either because the
marketplace consensus has formed, or that for the narrower market niche
that the profile addresses, there already is a consensus.)

In this specific case, the profile for the folks who think not clearing
the set user ID bit is brain-dead would require a shall; for others
they could leave it alone, or maybe even require "shall not".

Sidelight:  Because I work for a vendor, I shudder to think that "shall
not" would ever actually be required for this case; this makes a problem
for vendors in that now we have to have another implementation option (or two
different implementations!).  It also makes problems for users because
it will cost more to implement the option (OK, not much, but they add
up) which will be passed on to the user, and the costs of administering
go up (again, they add up in complexity, probably geometrically).
Formal profiles (again, such as X/Open or NIST or IEEE) help assure
consistency in the choice of options, making it easier to lower the cost
of implementation, which translates into lower costs for the customer.

Donn Terry
Chair, IEEE 1003.1

Speaking only for myself; no part of this should be construed as anything
but my opinion, and specifically not as the opinion of either IEEE or
my employer.  (I have to say this to keep IEEE happy; I don't blame
them for requiring it, given the consequences.)

Volume-Number: Volume 22, Number 141