Anonymous | Login | 2024-03-29 14:28 UTC |
Main | My View | View Issues | Change Log | Docs |
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 | 2019-06-10 08:55 | ||
Reporter | geoffclare | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
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 | ||||||
|
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 | |
2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |