On Thu, Jun 23, 2016 at 09:42:09AM +0200, Michael Kerrisk (man-pages) wrote: > Hi Jann, > > Thanks for your further review. Follow-up of one point below. > > On 06/23/2016 12:44 AM, Jann Horn wrote: > >On Wed, Jun 22, 2016 at 09:21:29PM +0200, Michael Kerrisk (man-pages) wrote: > >>On 06/21/2016 10:55 PM, Jann Horn wrote: > >>>On Tue, Jun 21, 2016 at 11:41:16AM +0200, Michael Kerrisk (man-pages) wrote: > > [...] > > >>>> The algorithm employed for ptrace access mode checking deter‐ > >>>> mines whether the calling process is allowed to perform the > >>>> corresponding action on the target process, as follows: > >>>> > >>>> 1. If the calling thread and the target thread are in the same > >>>> thread group, access is always allowed. > >>>> > >>>> 2. If the access mode specifies PTRACE_MODE_FSCREDS, then for > >>>> the check in the next step, employ the caller's filesystem > >>>> user ID and group ID (see credentials(7)); otherwise (the > >>>> access mode specifies PTRACE_MODE_REALCREDS, so) use the > >>>> caller's real user ID and group ID. > >>> > >>>Might want to add a "for historical reasons" or so here. > >> > >>Can you be a little more precise about "here", and maybe tell me why > >>you think it helps? > > > >I'm not sure, but it might be a good idea to add something like this at the > >end of 2.: > >"(Most other APIs that check one of the caller's UIDs use the effective one. > >This API uses the real UID instead for historical reasons.)" > > > >In my opinion, it is inconsistent to use the real UID/GID here, the > >effective one would be more appropriate. But since the existing code uses > >the real UID/GID and that's not a security issue for existing users of > >the ptrace API, this wasn't changed when I added the REALCREDS/FSCREDS > >distinction. > > > >I think that for a reader, it might help to point out that in most cases, > >when a process is the subject in an access check, its effective UID/GID > >are used, and this is (together with kill()) an exception to that rule. > >But you're the expert on writing documentation, if you think that that's > >too much detail / confusing here, it probably is. > > Okay -- got it now, I think. I made this text: > > 2. If the access mode specifies PTRACE_MODE_FSCREDS, then, for > the check in the next step, employ the caller's filesystem > UID and GID. (As noted in credentials(7), the filesystem > UID and GID almost always have the same values as the cor‐ > responding effective IDs.) > > Otherwise, the access mode specifies PTRACE_MODE_REALCREDS, > so use the caller's real UID and GID for the checks in the > next step. (Most APIs that check the caller's UID and GID > use the effective IDs. For historical reasons, the > PTRACE_MODE_REALCREDS check uses the real IDs instead.) Thanks, that sounds good.
Attachment:
signature.asc
Description: Digital signature
