Notes |
(0001531)
nick (manager)
2013-04-04 16:18
edited on: 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.
|
|
(0001533)
geoffclare (manager)
2013-04-05 09:02
|
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. |
|
(0001534)
joerg (reporter)
2013-04-05 10:17
|
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. |
|
(0001535)
jilles (reporter)
2013-04-05 18:34
|
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. |
|
(0001815)
ajosey (manager)
2013-09-06 04:57
|
Interpretation Proposed 6 Sep 2013 |
|
(0001888)
ajosey (manager)
2013-10-14 13:05
|
Interpretation approved 14 October 2013 |
|