Retaining file permissions
Alex Martelli
martelli at cadlab.sublink.ORG
Fri Mar 8 20:18:41 AEST 1991
Submitted-by: martelli at cadlab.sublink.ORG (Alex Martelli)
Thanks to Donn Terry and the others responding, both here and by Email;
now I understand the S_ISUID/S_ISGID issue better!
donn at hpfcrn.fc.hp.com (Donn Terry) writes:
...
: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".)
...
: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
...but NOT here; indeed, digging into XPG3 I find in vol 2 pg 519 at the
end of the Description of write(): "...and if the file is a regular
file, the S_ISUID and S_ISGID bits of the file mode may be cleared".
Indeed, the "may" sounds to my non-native-speaker ears as even weaker
than the "should"... so I guess that as a multiplatform application
developer I definitely HAVE TO learn to live with both behaviors (the
chmod() page of XPG3 also has threateninly mysterious caveats about what
is or is not done with S_ISUID/S_ISGID, so it won't necessarily be easy
to compensate for varying behavior of write() in this respect, alas...).
--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli at cadlab.sublink.org, (home:) alex at am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
Volume-Number: Volume 23, Number 3
More information about the Comp.std.unix
mailing list