site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com --Jim _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Sep 16, 2004, at 4:17 AM, Ryan McGann wrote: Does anybody out there know what SecToken in MIG definition files are used for, and where I can find out more about them? I have some MIG definitions as part of some sample code that use SecToken and AuditToken parameters, but then the source does nothing with them (except the MIG generated source). I'm curious as to how they would be used in "the real world". Requesting the Mach security token be appended to a Mach message trailer, and then exposing it through MIG RPC interfaces by means of these keywords, is the Mach equivalent of calling the local-socket getpeereid(3) interface - but on a message-by-message basis. That is, a structure containing the effective uid, and effective gid of the sending process, is filled in by the kernel in a "trusted path" (unspoofable) way for each message that arrives. MIG determines the presence of this structure in the trailer, and provides it as a "magic" parameter to the RPC call. The SecToken keyword is the "symmetrical" option. Both the client and the server see the security token of the other. Other options are asymmetrical - and provide the token only on one side of the interface or the other (prototypes for client and server don't match in these cases). As we started down the path of providing a full-featured auditing system to Darwin/Mac OS X (a work still in progress), we realized that we needed additional information be added to the trailers in order to cut a meaningful audit record during such an RPC. Because of the limited size of the data available in the existing security token structure - and because people have discerned the meaning of the fields in the opaque structure definition over time - we needed to add a new (expanded) token to contain the audit information (rather than alter the old). Just as originally intended for the security token, the structure is meant to be opaque. But this time we are adding library routines to the audit library in order to access the contents from the very beginning. Of course, neither are finalized yet until the audit mechanism "goes live." So, you really can't meaningfully use this mechanism yet. As identities become even more complex (e.g. ACL system already announced for Tiger), we will likely be providing even more options for managing identities through Mach IPC. Future options will likely return counted references to full credentials - allowing much more robust authorizations to be requested. Stay tuned for that. PS: One trick: You have to make sure your runloop/serverloop provides the proper options to receive the Mach message trailers that contain these tokens. These options are identified in <mach/message.h>. This email sent to site_archiver@lists.apple.com