I get that you want to use UIDs for these things, but that's wishful thinking. You're assuming properties about a process's UID that are not guaranteed. See set

I get that you want to use UIDs for these things, but that's wishful thinking. You're assuming properties about a process's UID that are not guaranteed. See setuid(2) for example, or passing an fd from another process. The reason you leave these things to the kernel is the kernel is the only place that can actually make the proper security determination. A file-permission analogy: it is a bad idea to stat(2) a file to probe if it's possible to open it. The kernel already provides that capability, which you have to handle anyway. The proper design is to open the file, and handle the EACCES error. Testing first doesn't work because the situation can change between the stat(2) and the open(2). > configuring wireless networks There are many ways to handle that, which do not require abusing UIDs for security features they weren't designed for. edit: No, I absolutely am not agreeing with you. Using UIDs for security outside the kernel (which is where the assurances your new kernel feature would provide will end up) is fundamentally broken. It works inside the kernel because the kernel can lock whatever is necessary. You are only moving the race condition. You ask your new interface for the sender's UID, an interrupt happens, and the data you got may no longer be valid as the sender called setuid().