On Tue, Mar 18, 2025 at 03:43:07AM +0000, Parav Pandit wrote: > > I would say no, that is not our model in RDMA. The process that opens the file > > is irrelevant. We only check the current system call context for capability, > > much like any other systemcall. > > > Eric explained the motivation [1] and [2] for this fix is: > A lesser privilege process A opens the fd (currently caps are not > checked), passes the fd to a higher privilege process B. > And somehow let process B pass the needed capabilities check for > resource creation, after which process A continue to use the > resource without capability. Yes, I'd say that is fine within our model, and may even be desirable in some cases. We don't use a file descriptor linked security model, it is always secured based on the individual ioctl system call. The file descriptor is just a way to route the system calls. The "setuid cat" risk is interesting, but we are supposed to be preventing that by using ioctl, no 'cat' program is going to randomly execute ioctls on stdout. You would not say that if process B creates a CAP_NET_RAW socket FD and passes it to process A without CAP_NET_RAW then A should not be able to use the FD. The same principle holds here too, the object handles scoped inside the FD should have the same kind of security properties as a normal FD would. Jason
