Hi Andy, On 01/29/2015 01:09 PM, Andy Lutomirski wrote: > On Jan 29, 2015 6:42 AM, "Daniel Mack" <daniel@xxxxxxxxxx> wrote: >> As we explained before, currently, D-Bus peers do collect the same >> information already if they need to have them, but they have to do deal >> with the inherit races in such cases. kdbus is closing the gap by >> optionally providing the same information along with each message, if >> requested. > > In all these discussions, no one ever gave a decent example use case. > If a process drops some privilege, it must close all fds it has that > captured its old privilege. This has nothing to do with kdbus. kdbus does not implement any new concept here but sticks to what SCM_CREDENTIALS does on SOL_SEQPACKET. An application can get a file-descriptor from socket() or socketpair() and freely pass it around between different tasks or threads, but messages will always have the credentials attached that are valid at *send* time. SO_PEERCREDS, however, still reports the connect-time credentials, and kdbus provides exactly the same semantics and both ways of retrieving information. > I agree that the design seems to have improved to a state of being at > least decent, One reason for that is your feedback. Thanks for that again! > It's an optional feature that will get used, non-optionally, thousands > of times on each boot, apparently. Keep in mind that it's also a > scalability problem because it takes locks. If it ever gets used > thousands of times per CPU on a big thousand-core machine, it's going > to suck, and you'll have backed yourself into a corner. That's right, but again - if an application wants to gather this kind of information about tasks it interacts with, it can do so today by looking at /proc or similar sources. Desktop machines do exactly that already, and the kernel code executed in such cases very much resembles that in metadata.c, and is certainly not cheaper. kdbus just makes such information more accessible when requested. Which information is collected is defined by bit-masks on both the sender and the receiver connection, and most applications will effectively only use a very limited set by default if they go through one of the more high-level libraries. Also, when metadata is collected, the code mostly takes temporary references on objects like PIDs, namespaces etc. Which operation would you consider particularly expensive? Thanks again, Daniel -- 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
