View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001024 | 1003.1(2013)/Issue7+TC1 | System Interfaces | public | 2016-01-26 20:31 | 2024-06-11 08:58 |
| Reporter | Clausecker | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Omission |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Robert Clausecker | ||||
| Organization | Fraunhofer FOKUS | ||||
| User Reference | |||||
| Section | chmod() | ||||
| Page Number | 660 | ||||
| Line Number | 22352–22353 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0001024:0003506 | ||||
| Summary | 0001024: chmod() should be allowed to ignore S_ISVTX | ||||
| Description | The chmod() page does not specify that a request to set the S_ISVTX bit may be silently ignored. This however is historic practice since at least V7 UNIX and the behaviour observed in some certified systems (e.g. Solaris). I assume this was simply forgotten. | ||||
| Desired Action | Change lines 22352–22353 from Additional implementation-defined restrictions may cause the S_ISUID and S_ISGID bits in mode to be ignored. to Additional implementation-defined restrictions may cause the S_ISUID, S_ISGID and S_ISVTX bits in mode to be ignored. With an appropriate XSI margin code around “and S_ISVTX.” | ||||
| Tags | tc3-2008 | ||||
|
|
The exclusion from that clause is intended, iirc (as part of the discussion of Bug #838). As written a system claiming conformance, XSI or as an extension to base POSIX, will not ignore the bit; support for setting it is required if <stat.h> declares it. The circumstances where it can't or shouldn't be set or cleared on the media is accounted for by the EINVAL, EPERM, or EROFS error cases. Whether it gets ignored after being set due to an application having elevated privileges affects other interfaces, not chmod(). The S_ISUID and GID bits are exceptions so an unprivileged application can't elevate a file's privileges if accessed subsequently by a privileged user. The EINVAL catchall case could also be a 'shall fail' error if the media format does not support recording some of the bits specified to be set, and have the 'may fail' case specifically for if bits are set which do not correspond to any S_* macro. |
|
|
The named systems do not ignore the bit, they just ignore it in case that the caller does not have the privileges to set it. It seems that we should permit existing practice since 40 years that exists on certified systems like Solaris or HP-UX. AIX seems to be the only certified more or less "genetic" UNIX that prints an error message in this case. |
|
|
Dunno, longstanding or not, that is what EPERM covers as a 'shall fail' case, for Issue 6 too. If they passed it's a bug in the test suite, it appears. |
|
|
If this is how UNIX implementation behaved during the past 40 years, I cannot believe that this could be interpreted as something different than a POSIX bug. The intention of POSIX is to describe the behavior of UNIX systems, not to introduce new rules that are in conflict with existing behavior. |
|
|
I think this bug may be mixing up the two different uses of S_ISVTX. The standard only covers the use of S_ISVTX on directories (XBD 4.2 says "If the S_ISVTX bit is set on a non-directory file, the behavior is unspecified.") Do the systems in question have circumstances where they silently ignore S_ISVTX when changing the mode of a directory, or only of a non-directory file? |
|
|
ENOTDIR covers that, also as 'shall fail', as a change from XBD 4 or 5, it seems. If they were 'may fail' then I'd agree the intent was ambiguous, but only EINVAL is now (and possibly shouldn't be, per above). I'm thinking either 1003.1 or SUSV5 was stricter than the other, so despite backwards incompatibility it made it into V6 as an error and no longer ignorable, as the 'safer' choice; but test suite still using test cases that didn't check error being properly returned. |
|
|
The systems in question ignore S_ISVTX for files when the user does not have the needed privileges to set the bit. For directories S_ISVTX is not ignored. |
|
|
At least one system (OpenBSD) consequently ignores attempts to set S_ISVTX, even if attempted by the superuser. |
|
|
Re: 0003039 Clausecker, testing on OpenBSD-current, i cannot reproduce. When calling chmod(..., S_ISVTX) on a directory, i get success, no change to errno, and the directory ends up with mode 01000. On a regular file, i get failure, errno set to EFTYPE, and no change to the file modes. So far for a normal user. As root, the same for a directory, but i get success, no change to errno, and mode 01000 even for a regular file. On first sight, i don't see any case where anything is silently ignored. |
|
|
So OpenBSD behaves similar to AIX, except that it uses an illegal errno. The value EFTYPE was introduced on *BSD in 1990 for content errors in /etc/fstab or in the disk partitioning. |
|
|
schwarze, I'm sorry for my incorrect claim. The following is documented in the OpenBSD manpage: If mode ISVTX (the sticky bit) is set on a file, it is ignored. I trusted the manpage but testing confirms your report. It seems like the manpage is incorrect. |
|
|
That would be a case where it got set in a non-directory on-disk descriptor, as 'file', by a means other than a non-priveleged chmod(). That the interface allows it in superuser mode could be considered a bug left over from ISTXT using the same bit position in earlier versions, perhaps, but su stuff out of scope for POSIX. I'd think the interfaces that test for the bits presence or absence would be expected to ignore it those regular files as irrelevant. |
|
|
Re: 0003042 Clausecker, the manual isn't incorrect, the wording is merely slightly ambiguous. The intended meaning is *not* "the attempt to set it is ignored and the bit won't be set", but the intended meaning is "later on, the fact that the bit is now set will be ignored by the rest of the system, it doesn't matter whether or not the bit is set on a file (as opposed to on a directory)". That becomes clearer from the context, in particular the following sentence in that manual page. But this is getting off-topic, if i understand 0003036 correctly, POSIX only specifies the effect of S_ISVTX for directories, so it shouldn't matter to POSIX what some operating system does with it when applied to regular files. Yes, throwing EFTYPE looks slightly suspicious, i'm not completely convinced that's ideal, but at worst, that's a case of non-conformance in our code. I'm not sure it should have any bearing on what the standard should require. |
|
|
A comparison of ufs/ufs_vnops.c:chmod1() in 4.3BSD-Reno and Net2 shows the transition from silently suppressing S_ISVTX on non-directories to return EFTYPE happened between them, in late 1990 early 1991. Anyone have the SCCS files to see what Kirk's commit message was? ;-) With that behavior in Net2 and then 4.4BSD, it of course ended up in all the later BSDs, Free, Net, and Open. |
|
|
You may be thinking of this change: https://github.com/jonathangray/csrg/blob/3f86276982ac68fb117ead4a73acaac8c6ca0485/sys/ufs/ufs/ufs_vnops.c |
|
|
Better link: https://github.com/jonathangray/csrg/commit/4fbceac9fb3bbbffba76bbc1989393837c901c9e#diff-30aeaac7b80c2a09d2bb3013eaf478a9 |
|
|
Here is the delta message retrieved via "SCCS -R log" on the whole project: Fri Dec 14 12:40:40 1990 bostic * ./sys/ufs/ffs/ffs_vnops.c 7.48 * ./sys/ufs/ffs/ufs_vnops.c 7.48 * ./sys/ufs/lfs/lfs_vnops.c 7.48 * ./sys/ufs/ufs/ufs_vnops.c 7.48 fail if try to set VTX on file not of type directory, or GID and not member of the group So it was not Kirk but rather Keith Bostic, the same person who introduced the error code. Here is the annotated code sniplet retrived via "sccs get -p -A -m -r7.48":
4.21 root 82/03/18 /*
4.42 sam 82/11/13 * Change the mode on a file.
4.42 sam 82/11/13 * Inode must be locked before calling.
4.42 sam 82/11/13 */
7.7 mckusick 89/05/09 chmod1(vp, mode, cred)
7.7 mckusick 89/05/09 register struct vnode *vp;
4.32 sam 82/08/10 register int mode;
7.7 mckusick 89/05/09 struct ucred *cred;
4.32 sam 82/08/10 {
7.7 mckusick 89/05/09 register struct inode *ip = VTOI(vp);
7.9 mckusick 89/05/09 int error;
4.35 root 82/08/24
7.9 mckusick 89/05/09 if (cred->cr_uid != ip->i_uid &&
7.9 mckusick 89/05/09 (error = suser(cred, &u.u_acflag)))
7.9 mckusick 89/05/09 return (error);
7.7 mckusick 89/05/09 if (cred->cr_uid) {
7.48 bostic 90/12/14 if (vp->v_type != VDIR && mode & ISVTX)
7.48 bostic 90/12/14 return (EFTYPE);
7.48 bostic 90/12/14 if (!groupmember(ip->i_gid, cred) && mode & ISGID)
7.48 bostic 90/12/14 return (EPERM);
4.28 root 82/07/15 }
7.48 bostic 90/12/14 ip->i_mode &= ~07777;
7.7 mckusick 89/05/09 ip->i_mode |= mode & 07777;
4.21 root 82/03/18 ip->i_flag |= ICHG;
7.7 mckusick 89/05/09 if ((vp->v_flag & VTEXT) && (ip->i_mode & ISVTX) == 0)
7.47 mckusick 90/12/05 (void) vnode_pager_uncache(vp);
6.18 mckusick 85/05/22 return (0);
4.18 wnj 82/02/27 }
|
|
|
While use of EFTYPE is allowed as an extension, I think EINVAL is what people just reading the standard might expect, as an invalid bit for non-dir file types. |
|
|
shware_systems, I don't believe EINVAL is appropriate. Setting S_ISVTX on a non-directory is not an invalid operation. It is merely not allowed to do without appropriate permissions. The error code should be EPERM as the operation failed due to lack of permissions. |
|
|
If I create an archive on a non-BSD system containing regular files with the S_ISVTX bit set and try to unarchive those files and preserve file modes on a BSD system, it seems from the discussion in these notes that the file extraction will fail. But on other systems that don't support the S_ISVTX bit on regular files, the file would be extracted successfully with the sticky bit silently ignored. Is this difference viewed as a "feature" or a "bug" on BSD systems? |
|
|
Documented behavior. [EFTYPE] The effective user ID is not the super-user, the mode includes the sticky bit (S_ISVTX), and path does not refer to a directory. Note that you can still set the sticky bit with appropriate privilege, so the argument that [EPERM] would be a better error to use is legitimate, but contrary to history. [EFTYPE] has been documented since 1997. |
|
|
Re: 0001024:0003497 I understand that the behavior is documented. I was asking in 0001024:0003495 whether users find that documented behavior to be useful or to be a hindrance in doing what they need to do to get their jobs done. |
|
|
I think you would have to poll the users to find out. This is not a situation that comes up with any frequency, and my vague recollection is that setting the sticky bit on an executable (in the historical usage) always required appropriate privilege. Near as I can tell, there has never been a single bug report filed regarding this behavior. Also note that FreeBSD does not claim to implement the XSI option, so a bug report about this might be closed with a WONTFIX. I did not see any such reports, however. (Very early on there was one bug report -- about [EFTYPE] not being documented, not about the actual behavior.) |
|
|
Interpretation response ------------------------ The standard states the requirements for chmod(), and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- Existing practice on some systems is to ignore S_ISVTX for non-directory files in non-privileged processes. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Change lines 22352–22353 from: Additional implementation-defined restrictions may cause the S_ISUID and S_ISGID bits in mode to be ignored.to: Additional implementation-defined restrictions may cause the S_ISUID and S_ISGID bits in mode to be ignored, [XSI]and may cause the S_ISVTX bit in mode to be ignored for non-directory files[/XSI]. |
|
|
Note that the change in 0001024:0003506 still allows the BSD behaviour, since ignoring S_ISVTX is optional. |
|
|
Interpretation proposed: 15 Dec 2016 |
|
|
Interpretation Approved: 18 Jan 2017 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-01-26 20:31 | Clausecker | New Issue | |
| 2016-01-26 20:31 | Clausecker | Name | => Robert Clausecker |
| 2016-01-26 20:31 | Clausecker | Organization | => Fraunhofer FOKUS |
| 2016-01-26 20:31 | Clausecker | Section | => chmod() |
| 2016-01-26 20:31 | Clausecker | Page Number | => 660 |
| 2016-01-26 20:31 | Clausecker | Line Number | => 22352–22353 |
| 2016-01-27 15:51 | shware_systems | Note Added: 0003032 | |
| 2016-01-27 16:10 | joerg | Note Added: 0003033 | |
| 2016-01-27 16:20 | shware_systems | Note Added: 0003034 | |
| 2016-01-27 16:35 | joerg | Note Added: 0003035 | |
| 2016-01-27 16:36 | joerg | Note Edited: 0003035 | |
| 2016-01-27 16:39 | geoffclare | Note Added: 0003036 | |
| 2016-01-27 16:40 | geoffclare | Note Edited: 0003036 | |
| 2016-01-27 17:14 | shware_systems | Note Added: 0003037 | |
| 2016-01-27 17:26 | joerg | Note Added: 0003038 | |
| 2016-01-27 17:40 | Clausecker | Note Added: 0003039 | |
| 2016-01-27 18:05 | schwarze | Note Added: 0003040 | |
| 2016-01-27 18:10 | joerg | Note Added: 0003041 | |
| 2016-01-27 18:15 | Clausecker | Note Added: 0003042 | |
| 2016-01-27 21:11 | shware_systems | Note Added: 0003043 | |
| 2016-01-27 21:17 | schwarze | Note Added: 0003044 | |
| 2016-01-27 23:25 | philip-guenther | Note Added: 0003045 | |
| 2016-01-27 23:56 | dickey | Note Added: 0003046 | |
| 2016-01-27 23:58 | dickey | Note Added: 0003047 | |
| 2016-01-28 11:22 | joerg | Note Added: 0003048 | |
| 2016-01-28 11:23 | joerg | Note Edited: 0003048 | |
| 2016-01-28 11:24 | joerg | Note Edited: 0003048 | |
| 2016-01-28 11:26 | joerg | Note Edited: 0003048 | |
| 2016-01-28 11:26 | joerg | Note Edited: 0003048 | |
| 2016-01-28 19:00 | shware_systems | Note Added: 0003055 | |
| 2016-01-28 19:05 | Clausecker | Note Added: 0003056 | |
| 2016-11-17 17:37 | Don Cragun | Note Added: 0003495 | |
| 2016-11-17 21:24 | GarrettWollman | Note Added: 0003497 | |
| 2016-11-17 22:20 | Don Cragun | Note Added: 0003498 | |
| 2016-11-17 23:06 | GarrettWollman | Note Added: 0003499 | |
| 2016-12-01 16:19 | geoffclare | Note Added: 0003506 | |
| 2016-12-01 16:21 | geoffclare | Interp Status | => Pending |
| 2016-12-01 16:21 | geoffclare | Final Accepted Text | => 0001024:0003506 |
| 2016-12-01 16:21 | geoffclare | Note Added: 0003507 | |
| 2016-12-01 16:21 | geoffclare | Status | New => Interpretation Required |
| 2016-12-01 16:21 | geoffclare | Resolution | Open => Accepted As Marked |
| 2016-12-01 16:21 | geoffclare | Tag Attached: tc3-2008 | |
| 2016-12-01 16:23 | geoffclare | Note Edited: 0003506 | |
| 2016-12-15 18:08 | ajosey | Interp Status | Pending => Proposed |
| 2016-12-15 18:08 | ajosey | Note Added: 0003515 | |
| 2017-01-18 15:22 | ajosey | Interp Status | Proposed => Approved |
| 2017-01-18 15:22 | ajosey | Note Added: 0003545 | |
| 2019-10-21 14:10 | geoffclare | Status | Interpretation Required => Applied |
| 2024-06-11 08:58 | agadmin | Status | Applied => Closed |
