>The whole point being that _nobody_ has it opened. It was attached to a
>packet when sender called sendmsg(). That is, set of descriptors passed
>by caller of sendmsg() had been converted into the set of struct file *
>When recvmsg() is called by the receiving side this set is either dropped
>(if caller of recvmsg() didn't expect files sent) or is passed into
>receivers table of opened files. I.e. new descriptors are created and
>files are attached to them. That's how it works. However, it happens only
>when the packet is received. If the process sends it and closes his
>descriptors - well, files are still alive (they are referenced from the
>packet) but they do not belong to any process at that moment. Now, send
>such packet to yourself and never call recvmsg(). And close the
>descriptors.
It can be fixed by exporting the in flight informations via /proc. Just
browse all unix sockets and then look at the per-sock in-flight packets
(UNIXCB(skb).fp field). The only brainer part should be the locking.
Then fuser can be changed to check the unix in-flight /proc info too.
I have not tried if lsof just catches these in flight fds (I really bet no).
If the number of security troubles is > 1, that's not a good point to left
all them not fixed IMHO.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/