home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: martelli@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@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@cadlab.sublink.org, (home:) alex@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
-
-