View Issue Details

IDProjectCategoryView StatusLast Update
00006751003.1(2008)/Issue 7System Interfacespublic2019-06-10 08:55
Reporterphilip-guenther Assigned Toajosey  
PrioritynormalSeverityEditorialTypeOmission
Status ClosedResolutionAccepted As Marked 
NamePhilip Guenther
OrganizationOpenBSD
User Reference
Sectionfcntl
Page Number810
Line Number27013
Interp StatusApproved
Final Accepted TextSee 0000675:0001531
Summary0000675: fcntl(fd, F_SETOWN, pid) error returns
DescriptionIf the provided pid or -pgrp doesn't exist, existing implementation have fcntl() returning -1 and setting errno to ESRCH.
Desired ActionAdd to the ERRORS 'shall' section something similar to:

[ESRCH] The cmd argument is F_SETOWN and no process or process group can
          be found corresponding to that specified by pid.


(Editorial side note: the [ENOLCK] entry says "The argument cmd" instead of "The cmd argument" like the other error entries do; it should be made consistent with the others.)
Tagstc2-2008

Relationships

related to 0000677 Closedajosey Omissions for fcntl() F_GETOWN and F_SETOWN 

Activities

nick

2013-04-04 16:18

manager   bugnote:0001531

Last edited: 2013-04-25 15:55

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:
-------------
Known existing implementations use ESRCH for this error.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

(Using page and line numbers from TC1-d3):
At page 816 after line 27394 add:

[ESRCH] The cmd argument is F_SETOWN and no process or process group can
          be found corresponding to that specified by arg.


At page 817 after line 27398 add:

[EINVAL] The cmd argument is F_SETOWN and the value of the argument is not valid as a process or process group identifier.

geoffclare

2013-04-05 09:02

manager   bugnote:0001533

Another related omission that we could fix at the same time is that
the description of F_GETOWN does not say what is returned if no
F_SETOWN has been done for the socket. Existing practice is
for fcntl() to return zero. Likewise, the description of
F_SETOWN does not say what happens if arg is zero. Presumably
this "cancels" a previous F_SETOWN, returning the socket to
having no owner, although I haven't tried it.

joerg

2013-04-05 10:17

reporter   bugnote:0001534

Just a note: On Solaris, all kernel processes and the init process have the process group ID 0 and no process has pgid == 1.

Solaris returns EINVAL in case that the fd is not a suitable arg (e.g. no socket).

Solaris returns ESRCH in case of F_SETOWN and pid == -1
Solaris returns EPERM in case of F_SETOWN and pid == 1 (non-root).

So Solaris also checks whether the process would be allowed to send signals to the target process.

jilles

2013-04-05 18:34

reporter   bugnote:0001535

A security check at F_SETOWN time alone is insufficient because the target's credentials may change, and also because permission to send signals may be limited to a subset of a process group (kill() then succeeds but silently skips processes you don't have permission to signal).

FreeBSD stores the credentials of the process doing F_SETOWN and performs a normal permission check using those when sending SIGIO or SIGURG. Because there is no way to report errors at that point, the signal is silently discarded if permission is denied. At F_SETOWN time, it checks that the target is in the same session as the caller. An even more paranoid implementation would only allow the process itself.

FreeBSD also allows unsetting an owner by using F_SETOWN with arg=0.

The Linux man page also says credentials are remembered.

A further omission is what happens if the owner process terminates or the owner process group becomes empty. FreeBSD unsets the owner in that case, as if F_SETOWN had been called with arg=0. For a process, this happens when the process terminates (so not when the zombie is reaped) and for a process group, this happens when the process group becomes completely empty (no zombies either). This latter detail only matters for F_GETOWN since signaling a zombie process does nothing.

ajosey

2013-09-06 04:57

manager   bugnote:0001815

Interpretation Proposed 6 Sep 2013

ajosey

2013-10-14 13:05

manager   bugnote:0001888

Interpretation approved 14 October 2013

Issue History

Date Modified Username Field Change
2013-03-31 06:19 philip-guenther New Issue
2013-03-31 06:19 philip-guenther Status New => Under Review
2013-03-31 06:19 philip-guenther Assigned To => ajosey
2013-03-31 06:19 philip-guenther Name => Philip Guenther
2013-03-31 06:19 philip-guenther Organization => OpenBSD
2013-03-31 06:19 philip-guenther Section => fcntl
2013-03-31 06:19 philip-guenther Page Number => 810
2013-03-31 06:19 philip-guenther Line Number => 27013
2013-04-04 16:18 nick Note Added: 0001531
2013-04-04 16:18 nick Interp Status => Pending
2013-04-04 16:18 nick Final Accepted Text => See 0000675:0001531
2013-04-04 16:18 nick Status Under Review => Interpretation Required
2013-04-04 16:18 nick Resolution Open => Accepted As Marked
2013-04-04 16:19 nick Tag Attached: tc2-2008
2013-04-04 16:23 nick Note Edited: 0001531
2013-04-04 16:30 nick Note Edited: 0001531
2013-04-04 16:30 nick Resolution Accepted As Marked => Open
2013-04-04 16:31 nick Note Edited: 0001531
2013-04-05 09:02 geoffclare Note Added: 0001533
2013-04-05 10:17 joerg Note Added: 0001534
2013-04-05 18:34 jilles Note Added: 0001535
2013-04-11 15:28 nick Resolution Open => Accepted As Marked
2013-04-12 15:34 geoffclare Relationship added related to 0000677
2013-04-25 15:55 nick Note Edited: 0001531
2013-09-06 04:57 ajosey Interp Status Pending => Proposed
2013-09-06 04:57 ajosey Note Added: 0001815
2013-10-14 13:05 ajosey Interp Status Proposed => Approved
2013-10-14 13:05 ajosey Note Added: 0001888
2019-06-10 08:55 agadmin Status Interpretation Required => Closed