"D. J. Bernstein" <djbat_private> wrotes: > Costs. It shouldn't take more than five minutes for a kernel implementor > to support getpeereuid(). For example, Linux has "struct ucred peercred" > inside struct sock, and a SO_PEERCRED macro in sys/socket.h, used by the > following four syscalls: > . . . > There's similar code to handle gid (and pid). The entire implementation > is about twenty lines long. Hmm. I admire the amount of careful design and validation that you seem to regard as necessary for kernel modifications. For example, consider the following sequence of operations: Process A running with effective uid fred and saved uid root creates a socket, and then changes to effective uid joe. Process B connects to the other end, process A changes to effective uid alf, and then process B calls getpeereuid. The following questions immediately spring to mind: 1) Which uid (fred, joe or alf) will it return? 2) Are there any circumstances under which it won't? 3) Is this the correct behaviour, anyway? 4) Are we sure that everyone will agree and do the same? This is definitely a facility that could be useful. But surely we know that designing operating system primitives for security enhancement needs long and careful thought, to avoid obscure and subtle design errors that cannot be fixed later? Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm1at_private Tel.: +44 1223 334761 Fax: +44 1223 334679
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:26 PDT