On Mon, Jan 13, 2020 at 12:42 PM Christian Brauner
[off-list ref] wrote:

On Mon, Jan 13, 2020 at 11:27:03AM -0800, Daniel Colascione wrote:

quoted

On Mon, Jan 13, 2020 at 11:10 AM Christian Brauner
[off-list ref] wrote:

quoted

This does not
affect the permission checking you're performing here.

Pidfds-as-capabilities sounds like a good change. Can you clarify what
you mean here though? Do you mean that in order to perform some
process-directed operation X on process Y, the pidfd passed to X must
have been opened with PIDFD_CAP_X *and* the process *using* the pidfds
must be able to perform operation X on process Y? Or do pidfds in this
model "carry" permissions in the same way that an ordinary file
descriptor "carries" the ability to write to a file if it was opened
with O_WRONLY even if the FD is passed to a process that couldn't
otherwise write to that file? Right now, pidfds are identity-only and
always rely on the caller's permissions. I like the capability bit
model because it makes pidfds more consistent with other file
descriptors and enabled delegation of capabilities across the system.

I'm going back and forth on this. My initial implementation has it that
you'd need both, PIDFD_FLAG/CAP_X and the process using the pidfd must
be able to perform the operation X on process Y. The alternative becomes
tricky for e.g. anything that requires ptrace_may_access() permissions
such as getting an fd out from another task based on its pidfd and so
on.

I think the alternative is necessary though. What's the point of the
pidfd capability bits if they don't grant access? If I have a pidfd
for Y that doesn't let me do operation X, but I have ambient authority
to do Y anyway, then I can just make my own pidfd for Y and then use
that new pidfd to do X. AFAICT, pidfd capabilities only do something
when they replace ptrace_may_access and friends for access control.
Otherwise, they seem purely advisory. Am I missing something?