Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000677 [1003.1(2008)/Issue 7] System Interfaces Objection Omission 2013-04-12 15:33 2013-10-14 13:06
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Interpretation Required  
Name Geoff Clare
Organization The Open Group
User Reference
Section fcntl
Page Number 807-808
Line Number 26911-26920
Interp Status Approved
Final Accepted Text See Note: 0001540.
Summary 0000677: Omissions for fcntl() F_GETOWN and F_SETOWN
Description During discussion of 0000675 some additional omissions in the
descriptions of F_GETOWN and F_SETOWN came to light:

1. The description of F_GETOWN does not say what is returned if no
F_SETOWN has been done for the socket. On at least 4 systems,
existing practice is for fcntl() to return zero. The suggested
changes mandate this behaviour.

2. Given that zero is a special return value, the question arises of
what F_SETOWN should do if the arg value is zero. On at least 4
systems, existing practice is to reset the ownership of the socket
so that no process or process group receives its SIGURG signals.
The suggested changes mandate this behaviour.

3. The standard does not mention the need for permission checks
equivalent to kill() to be performed. Implementations differ as to
whether they perform permission checks when fcntl() is called;
however, it is believed they all perform the checks when the SIGURG
signal is sent (because not to do so would be a security hole if a
targeted process changes its user IDs or privileges). The suggested
changes mandate permission checks at the time the signal is sent, but
leave it optional whether any permission checks are performed when
fcntl() is called with F_SETOWN.

4. The standard does not say what happens if the owner process
terminates or the owner process group becomes empty. Implementations
need to ensure that SIGURG signals are not sent to an unrelated
process which has been given a reused process ID. This could be
achieved either by resetting the ownership of the socket when the
process terminates (or is waited for) or the process group becomes
empty, or perhaps by other means such as marking the process ID or
process group ID as unavailable for reuse when the F_SETOWN is done.
It is known that some systems do the former and some do not; it has
not been established whether those that do not do the former use
some other method (but if they currently do neither, then they should
change). The suggested changes try to give implementations as much
leeway as possible while ensuring SIGURG signals will not be sent to a
process which has been given a reused process ID.

For the record, the 4 systems mentioned above are Solaris, HP-UX and
Linux, all tested by me; and FreeBSD, as reported by "jilles" in
Note: 0001535.
Desired Action Replace the F_GETOWN and F_SETOWN descriptions with:

F_GETOWN If fildes refers to a socket, get the process ID or process
    group ID specified to receive SIGURG signals when out-of-band data
    is available. Positive values shall indicate a process ID; negative
    values, other than -1, shall indicate a process group ID; the value
    zero shall indicate that no SIGURG signals are to be sent. If
    fildes does not refer to a socket, the results are unspecified.

F_SETOWN If fildes refers to a socket, set the process ID or process
    group ID specified to receive SIGURG signals when out-of-band data
    is available, using the value of the third argument, arg, taken as
    type int. Positive values shall indicate a process ID; negative
    values, other than -1, shall indicate a process group ID; the value
    zero shall indicate that no SIGURG signals are to be sent. Each
    time a SIGURG signal is sent to the specified process or process
    group, permission checks equivalent to those performed by kill()
    shall be performed, as if kill() were called by a process with
    the same real user ID, effective user ID, and privileges that the
    process calling fcntl() has at the time of the call; if the kill()
    call would fail, no signal shall be sent. These permission checks
    may also be performed by the fcntl() call. If the process specified
    by arg later terminates, or the process group specified by arg
    later becomes empty, while still being specified to receive
    SIGURG signals when out-of-band data is available from fildes,
    then no signals shall be sent to any subsequently created process
    that has the same process ID or process group ID, regardless of
    permission; it is unspecified whether this is achieved by the
    equivalent of an fcntl(fildes, F_SETOWN, 0) call at the time the
    process terminates or is waited for or the process group becomes
    empty, or by other means. If fildes does not refer to a socket,
    the results are unspecified.

After page 811 line 27044 add to the "may fail" errors:

[EPERM]
    The cmd argument is F_SETOWN and the calling process does not have
    permission to send a SIGURG signal to any process specified by arg.

At page 812 line 27107 add a new paragraph to the APPLICATION USAGE
section:

    On systems which do not perform permission checks at the time of
    an fcntl() call with F_SETOWN, if the permission checks performed
    at the time the signal is sent disallow sending the signal to any
    process, the process that called fcntl() has no way of discovering
    that this has happened. A call to kill() with signal 0 can be
    used as a prior check of permissions, although this is no guarantee
    that permission will be granted at the time a signal is sent, since
    the target process(es) could change user IDs or privileges in the
    meantime.

At page 814 line 27172 add kill() to the SEE ALSO list for fcntl().
Tags tc2-2008
Attached Files

- Relationships
related to 0000675Interpretation Requiredajosey fcntl(fd, F_SETOWN, pid) error returns 

-  Notes
(0001540)
Don Cragun (manager)
2013-04-18 16:07

Interpretation response
------------------------

The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
All existing implementations already perform as specified above.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Make the changes suggested in the Desired Action.
(0001814)
ajosey (manager)
2013-09-06 04:56

Interpretation Proposed 6 Sep 2013
(0001889)
ajosey (manager)
2013-10-14 13:06

Interpretation approved 14 October 2013

- Issue History
Date Modified Username Field Change
2013-04-12 15:33 geoffclare New Issue
2013-04-12 15:33 geoffclare Status New => Under Review
2013-04-12 15:33 geoffclare Assigned To => ajosey
2013-04-12 15:33 geoffclare Name => Geoff Clare
2013-04-12 15:33 geoffclare Organization => The Open Group
2013-04-12 15:33 geoffclare Section => fcntl
2013-04-12 15:33 geoffclare Page Number => 807-808
2013-04-12 15:33 geoffclare Line Number => 26911-26920
2013-04-12 15:33 geoffclare Interp Status => ---
2013-04-12 15:34 geoffclare Relationship added related to 0000675
2013-04-18 16:07 Don Cragun Interp Status --- => Pending
2013-04-18 16:07 Don Cragun Note Added: 0001540
2013-04-18 16:07 Don Cragun Status Under Review => Interpretation Required
2013-04-18 16:07 Don Cragun Resolution Open => Accepted
2013-04-18 16:07 Don Cragun Final Accepted Text => See Note: 0001540.
2013-04-18 16:08 Don Cragun Tag Attached: tc2-2008
2013-09-06 04:56 ajosey Interp Status Pending => Proposed
2013-09-06 04:56 ajosey Note Added: 0001814
2013-10-14 13:06 ajosey Interp Status Proposed => Approved
2013-10-14 13:06 ajosey Note Added: 0001889


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker