> sorry I thought I had cc:d you, bc I was pretty sure you'd have some > neat ideas. Like this one. > > One could try to argue that this makes every linux process susceptible > to a trojan making it grant its userid to other tasks, but of course > that's silly since the trojan could just fork. Well, what this would > buy the attacker is the ability to sit inconspicuously under his old > userid, holding on to the fd until the admin goes out to coffee before > switching userids. Possibly, could you put a timestamp in the passed object ? (Given the expiry of such a uid offer is kind of policy) > The other thing is that offhand I think the server can't easily tell > from the socket which user namespace the client is in, as ucred only > has .uid. Though (1) we might need to create a 'struct puser' analogous > to 'struct pid' for signals anyway, (2) userspace can segragate with > fs or net_ns (if abstract sock), and (3) client in a container > presumably won't be able to authenticate itself to server on the > host anyway. That I think needs fixing anyway and now is a good time as any to do it. If you are going to be able to pass userids then you need to be sure you don't get passed a handle with a uid change on it that you didn't want so adding another object type and option of some kind to accept them has to occur anyway. That also btw needs fixing for other reasons - more than one daemon has been written that generically uses recvmsg and so can be attacked with FD leaks >-) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html