Hi Florian: The CAP_xxx portion of the dest_name_check() routine tires to ensure that the tipc-config commands requiring "administrator" priviliges can only be sent by processes having that privilege. You're right that it is possible (albeit awkward) to circumvent this check, but I think that we were only concerned about detecting accidental misuse of privileged operations by non-privileged users (for which the existing check is sufficient), rather than stopping deliberate misuse by unscrupulous users. To do the latter, we would probably have to change the design so that a separate TIPC address is used as the destination for privileged commands, rather than checking the content of the message being sent. I can add the issue to my list of potential work items, but I suspect it will get a low priority. Thanks for bringing it to my attention, though!
Regards, Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Florian Westphal Sent: Tuesday, June 05, 2007 5:29 PM To: [email protected] Subject: Re: [tipc-discussion] tipc may sleep with sk lock hold Stephens, Allan <[EMAIL PROTECTED]> wrote: [copy_to_user with sk lock held] > in the middle of an operation. My expectation is that a sleeping > copy_to_user() will only delay other threads from starting up new > operations on the socket for a short period of time. I asked because the 'locking policy' comment in tipc_socket.c gave the impression that locks would always be released before processes need to sleep, so i wanted to make sure that these copy_from/to cases were intentional. Thanks for the clarification. Actually, reading the locking policy again, the "need to sleep" probably implies "explicit" waits -- i missed that. Sorry. > There may be a risk that the data validated by dest_name_check() may > be out-dated by the time it is actually copied into the message > created by TIPC, but the risk of this seems minimal. Well... what is the purpose of that CAP_()-check if it can be circumvented? Better to not have it at all than a known-to-be-insufficient solution. YMMV... Disclaimer: I do not understand the implications and/or intentions of that check. > If someone wants to initiate > a send operation on a socket, and then have a second thread of control > modify the buffer area being used in the send, then they've created a > race condition that seems beyond TIPC's control to overcome. The obvious solution is to not copy that data a second time :) But yes, it looks difficult to do this right. I neither see an easy way to do such a check in msg_build or to tell msg_build to skip that part of the user buffer. Thanks, Florian ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
