A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1283 ====================================================================== Reported By: geoffclare Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1283 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section: chmod() Page Number: 665 Line Number: 22780 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2019-09-04 09:16 UTC Last Modified: 2019-09-04 22:40 UTC ====================================================================== Summary: should chmod() ignore file type bits in st_mode ======================================================================
---------------------------------------------------------------------- (0004548) kre (reporter) - 2019-09-04 22:40 http://austingroupbugs.net/view.php?id=1283#c4548 ---------------------------------------------------------------------- Re bugnote: 4547 There is nothing in posix (nor in some implementations) that suggests that a mode_t should be 16 bits (short). Adding bits is entirely possible (and needed to define new file types, if not so much for more permissions, which would be hard to do in a portable manner). Re the proposed resolution: I don't much like using 07777 as a "magic" number, even though the values of all the relevant bits are defined, and fit (exactly) into that value. Nor am I convinced that giving in to whatever implementation returned EINVAL is necessarily the corrcet thing to do. What would seem more reasonable to me would be to require implementations accept either all 0's in the "other" bits, or a value that exactly matches the current settings of those bits, and is permitted to return EINVAL only in cases where the application has attempted to use chmod to alter the state of those bits (if it isn't already required somewhere, I'd also add, somewhere, not related to chmod, a requirement that it is invalid to have all the other bits 0 for any existing file, whatever its type). EINVAL in cases where an attempt is made to set permissions that are impossible for the file in question is OK as well of course. Issue History Date Modified Username Field Change ====================================================================== 2019-09-04 09:16 geoffclare New Issue 2019-09-04 09:16 geoffclare Name => Geoff Clare 2019-09-04 09:16 geoffclare Organization => The Open Group 2019-09-04 09:16 geoffclare Section => chmod() 2019-09-04 09:16 geoffclare Page Number => 665 2019-09-04 09:16 geoffclare Line Number => 22780 2019-09-04 09:16 geoffclare Interp Status => --- 2019-09-04 17:10 shware_systems Note Added: 0004547 2019-09-04 22:40 kre Note Added: 0004548 ======================================================================
