View Issue Details

IDProjectCategoryView StatusLast Update
00010241003.1(2013)/Issue7+TC1System Interfacespublic2024-06-11 08:58
ReporterClausecker Assigned To 
PrioritynormalSeverityObjectionTypeOmission
Status ClosedResolutionAccepted As Marked 
NameRobert Clausecker
OrganizationFraunhofer FOKUS
User Reference
Sectionchmod()
Page Number660
Line Number22352–22353
Interp StatusApproved
Final Accepted Text0001024:0003506
Summary0001024: chmod() should be allowed to ignore S_ISVTX
DescriptionThe 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 ActionChange 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.”
Tagstc3-2008

Activities

shware_systems

2016-01-27 15:51

reporter   bugnote:0003032

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.

joerg

2016-01-27 16:10

reporter   bugnote:0003033

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.

shware_systems

2016-01-27 16:20

reporter   bugnote:0003034

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.

joerg

2016-01-27 16:35

reporter   bugnote:0003035

Last edited: 2016-01-27 16:36

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.

geoffclare

2016-01-27 16:39

manager   bugnote:0003036

Last edited: 2016-01-27 16:40

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?

shware_systems

2016-01-27 17:14

reporter   bugnote:0003037

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.

joerg

2016-01-27 17:26

reporter   bugnote:0003038

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.

Clausecker

2016-01-27 17:40

reporter   bugnote:0003039

At least one system (OpenBSD) consequently ignores attempts to set S_ISVTX, even if attempted by the superuser.

schwarze

2016-01-27 18:05

reporter   bugnote:0003040

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.

joerg

2016-01-27 18:10

reporter   bugnote:0003041

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.

Clausecker

2016-01-27 18:15

reporter   bugnote:0003042

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.

shware_systems

2016-01-27 21:11

reporter   bugnote:0003043

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.

schwarze

2016-01-27 21:17

reporter   bugnote:0003044

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.

philip-guenther

2016-01-27 23:25

reporter   bugnote:0003045

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.

dickey

2016-01-27 23:56

reporter   bugnote:0003046

You may be thinking of this change:

https://github.com/jonathangray/csrg/blob/3f86276982ac68fb117ead4a73acaac8c6ca0485/sys/ufs/ufs/ufs_vnops.c

dickey

2016-01-27 23:58

reporter   bugnote:0003047

Better link:

https://github.com/jonathangray/csrg/commit/4fbceac9fb3bbbffba76bbc1989393837c901c9e#diff-30aeaac7b80c2a09d2bb3013eaf478a9

joerg

2016-01-28 11:22

reporter   bugnote:0003048

Last edited: 2016-01-28 11:26

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        }


shware_systems

2016-01-28 19:00

reporter   bugnote:0003055

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.

Clausecker

2016-01-28 19:05

reporter   bugnote:0003056

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.

Don Cragun

2016-11-17 17:37

manager   bugnote:0003495

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?

GarrettWollman

2016-11-17 21:24

reporter   bugnote:0003497

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.

Don Cragun

2016-11-17 22:20

manager   bugnote:0003498

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.

GarrettWollman

2016-11-17 23:06

reporter   bugnote:0003499

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.)

geoffclare

2016-12-01 16:19

manager   bugnote:0003506

Last edited: 2016-12-01 16:23

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].


geoffclare

2016-12-01 16:21

manager   bugnote:0003507

Note that the change in 0001024:0003506 still allows the BSD behaviour, since ignoring S_ISVTX is optional.

ajosey

2016-12-15 18:08

manager   bugnote:0003515

Interpretation proposed: 15 Dec 2016

ajosey

2017-01-18 15:22

manager   bugnote:0003545

Interpretation Approved: 18 Jan 2017

Issue History

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